| |
| 2.2, Аноним (2), 08:21, 02/12/2024 [^] [^^] [^^^] [ответить]
| +5 +/– |
Может, и не врут, только вот сколько букв от ACID осталось?
| | |
| |
| 3.14, funny.falcon (?), 10:50, 02/12/2024 [^] [^^] [^^^] [ответить]
| +4 +/– |
Всё там с ACID в порядке. Архитектура Постгресса действительно не оптимальна в нынешних реалиях, и сделать что-то выделяющееся на её фоне вполне возможно.
| | |
| |
| 4.33, freebzzZZZzzd (ok), 17:57, 02/12/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
 >Всё там с ACID в порядке
а ты кто? вот когда jepsen пруфнет, тогда поверим.
у субд вообще много разных проблем, не только бинарное "acid да/нет".
по описанию вообще шг в сторону монго сделали ) осталось JSON нормально сделать и лет 5 повылизывать код. и получится что-то путнее
| | |
|
|
|
| |
| 2.10, chdlb (?), 10:16, 02/12/2024 [^] [^^] [^^^] [ответить]
| +6 +/– | |
а теперь смотрим как он считается:
Number of mentions of the system on websites, measured as number of results in search engines queries. At the moment, we use Google and Bing for this measurement. In order to count only relevant results, we are searching for <system name> together with the term database, e.g. "Oracle" and "database".
General interest in the system. For this measurement, we use the frequency of searches in Google Trends.
Frequency of technical discussions about the system. We use the number of related questions and the number of interested users on the well-known IT-related Q&A sites Stack Overflow and DBA Stack Exchange.
Number of job offers, in which the system is mentioned. We use the number of offers on the leading job search engines Indeed and Simply Hired.
Number of profiles in professional networks, in which the system is mentioned. We use the internationally most popular professional network LinkedIn.
Relevance in social networks. We count the number of Twitter (X) tweets, in which the system is mentioned.
т.е. достаточно, чтобы было много головняка - и упс, ты лидер на форумах или в поисковых запросах
это явно не то что ожидаешь под словом RANK, понимая его как некую функцию от качества продукта, неизвестну. функции, но от характеристик продукта, а не вот это вот всё
| | |
| |
| 3.30, нах. (?), 15:44, 02/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> это явно не то что ожидаешь под словом RANK
но хотя бы - интересно. И да, те у кого все работает, не будут оставлять хвалебные отзывы в "twitter events". А вот "оно опять %%!$!" - да.
Так что инфа полезная, главное уметь понять.
| | |
| 3.40, Прохожий (??), 01:36, 03/12/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> т.е. достаточно, чтобы было много головняка
1. То есть вот этот критерий "Number of job offers" вы в попытке построить свою логическую цепочку почему-то упустили. Почему?.
2. Кроме того, вот это "Frequency of technical discussions about the system" не обязательно обозначает "головняк", а ещё и богатство фич. Что имеется ввиду? У СУБД "А" таких фич нет, поэтому обсуждать там нечего. У СУБД "Б" такие фичи есть, поэтому их обсуждают.
3. Ещё одни фактор, который вы упустили - это "Number of profiles in professional networks". Что это означает? Это означает, что если специалистов по СУБД "Б" больше, чем специалистов по СУБД "Б", то, очевидно, СУБД "Б" более популярна. Не правда ли?
Подытожу. Вы выбрали для вашего вывода только те факты, которые удобны вам. То есть, просто подогнали их под себя, чтобы они не противоречили вашей картине мира. Имеете право, разумеется, но к объективности это не имеет никакого отношения. Я не говорю, что представленный хит-парад - идеальный. Но, думаю, он более-менее близок к реальному положению дел.
> это явно не то что ожидаешь под словом RANK, понимая его как некую функцию от качества продукта
Успехов вам создать свой собственный RANK по вашим критериям. Однако вряд ли у вас получится что-то действительно путное и лучшее, чем то, что есть. Почему? Потому что люди, которые выбирают СУБД для своих нужд в общем и целом не идиоты. То есть, смею предположить, часто (не всегда) их выбор вполне осознанный.
| | |
| |
| 4.41, Прохожий (??), 01:37, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Опечатка:
если специалистов по СУБД "Б" больше, чем специалистов по СУБД "А" - так правильно
| | |
| 4.43, chdlb (?), 09:18, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Я ничего не выбирал, а сказал, что этот ранк бессмысленный по своей сути и показывает НИЧЕГО.
> То есть вот этот критерий "Number of job offers" вы в попытке построить...
Number of job offers, не значит ровным счетом ничего? потому что его можно по-другому интерпретировать, например, дефицит кандидатов из-за нежелания связываться с той или иной СУБД, отсюда повышенный спрос - это все гадания на манной каше.
> то, очевидно, СУБД "Б" более популярна. Не правда ли?
- нет не правда. Но и опять-таки, какое отношение это имеет к ранку? Популярность - это не функция от качества.
> Подытожу. Вы выбрали для вашего вывода только те факты, которые удобны вам. То есть, просто подогнали их под себя, чтобы они не противоречили вашей картине мира.
Какая прекрасная ошибка выжившего ))) Знаешь больше, чем тупые люди, раздражают только псевдо-интеллектулы с самомнением. Ты сам подогнал мои ответы под нужный тебе знаменатель, чтобы блеснуть (нет) эрудицией, потому что очень хотелось оппонировать.
Я привел полный список критериев на суд каждого, и один пример от меня, который показывает, что ранк вполне может быть необъективным, и корелляция там неоднозначная. И не более...
P.S.
> Потому что люди, которые выбирают СУБД для своих нужд в общем и целом не идиоты.
Люди не идиоты? Пффф, вот это ты юморист...
| | |
|
|
|
| |
| 2.11, chdlb (?), 10:17, 02/12/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
а для всего постгреса шардинг, постгрес в принципе сильно переоценен
| | |
| |
| 3.47, Аноним (47), 12:13, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Шардинг это не про РСУБД вообще. Как слоить данные решение прикладного уровня, а не модельного.
| | |
| |
| 4.77, chdlb (?), 18:07, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
тот случай, когда даже электромоторчик из детской машинки умнее, чем очередной Аноним
погугли список распределенных RDBMS с шардингом на уровне бд - удивишься
а некоторые из них еще и синхронные, т.е полноценный multi-master
притом некоторые из них еще и кластерные с балансировкой нагрузки между нодами
| | |
| 4.79, chdlb (?), 18:15, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
теперь что касается "слоить", прикладной уровень, модельный - я такого дерьма в голове с терминологией не видел очень давно, потому что всячекски старался избегать дешевых бложиков
в БД у тебя не модели, а таблицы, будет ли отражено это на модели в предметной области (он же domain в DDD) - это еще вопрос
в любом случае даже если моя БД, будет из одной таблицы, она все равно может шардится... )))
что там под слоить понимаешь вообще никто не знает, как в принципе и "прикладной уровень", так то СУБД тоже "прикладной уровень" )))
| | |
|
|
|
| |
| 2.12, chdlb (?), 10:19, 02/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
это было бы логичным решением, но только если на замену родного движка, как подключаемый не вариант
| | |
| |
| 3.16, www2 (??), 10:53, 02/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
PostgreSQL - очень консервативная система. Пока что в виде подключаемого движка, потом, когда-нибудь, поменяют настройки и он по умолчанию будет использоваться при создании новых таблиц. Потом, глядишь, его начнут использовать большинство инсталляций. И только потом старый движок отключат, возможно, удалят, как устаревший.
Но всё это пока что вилами на воде писано. Надо хотя бы дождаться выпуска стабильной версии и доработки интерфейсов PostgreSQL для подключения этого движка без необходимости накладывать заплатки на исходный текст и пересобирать из исходников.
| | |
| |
| 4.18, нах. (?), 11:45, 02/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Пока что в виде подключаемого движка
оно уже перестало требовать патчить основной код, или как было?
Потому что это обещали два года назад.
| | |
| |
| 5.20, нах. (?), 11:54, 02/12/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
А, уже вижу - "with extensibility patches". Вот когда будут в мэйнлайне, тогда и приходите.
| | |
|
|
|
|
| 1.6, anguest (?), 09:11, 02/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
Попробовал предыдущий выпуск на реальной нагрузке. После определенного кол-ва запросов начинаются утечки памяти и все падает. Но надеюсь что допилят, очень нужная весчь.
| | |
| 1.17, ОООноним (?), 11:19, 02/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
>При выполнении операции UPDATE поддерживается замена данных по месту (без освобождения текущей записи и создания новой), что положительно сказывается на производительности.
Но ведь запись в конец при update и была сделана для повышения производительности. А теперь вернули как было и стало еще производительней?
| | |
| |
| 2.21, anonimus (?), 12:07, 02/12/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Но ведь запись в конец при update и была сделана для повышения производительности.
это про HOT, но не все апдейты можно сделать HOT, поэтому для ванильного посргре нагрузка на rewrite тех же строк - это беда. В то же время MySQL или OracleDB работают при такой нагрузке стабильно
| | |
| 2.22, inklesspen (ok), 12:17, 02/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Пару раз попрыгаем туда-сюда и будет еще производительнее =D
Неизвестно в какой среде проводились тесты, с какими дисками, с какими рейдами если они были и т.д. и т.п.
К тому же, обновлять данные по месту записи в любом случае надо: надо записать, что физическая запись устарела и более недействительна (т.е. установить значение t_xmax). Постгрес в этом случае просто делает двойную запись: в новое место новые данные и в старое место пометку. Да и не факт, что новая запись в конце.
Вот WAL да, это Append-Only log и писать там куда-то еще не требуется
| | |
| 2.63, Аноним (47), 15:29, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
В конец чего? Новая строка при update вставляется туда, где место есть, совсем не обязательно в конец чего-то.
| | |
|
| 1.23, Аноним (23), 14:54, 02/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Надо срочно пробовать. PostgreSQL жутко неповоротлив, как в работе, так и в разработке. Но альтернатив нет, к сожалению.
| | |
| 1.24, Аноним (24), 15:13, 02/12/2024 [ответить] [﹢﹢﹢] [ · · · ] | +/– | Сейчас 1733140900 PostgreSQL 1996-07-08, 836784000, 896356900 ago, 100 ago Ori... большой текст свёрнут, показать | | |
| |
| 2.31, Аноним (31), 15:58, 02/12/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
А кому нужно ровно 100% от функциональности продукта "П", ни процентом больше, ни процентом меньше? Мне вот например достаточно базового CRUD без выпендрёжа. Если оно в 10 раз быстрее чем конкуренты и без каких-то особых проблем то отлично, такое мы берём.
| | |
| 2.45, Alexander Korotkov (?), 10:48, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
 OrioleDB не является самостоятельной СУБД. Это небольшой патч к ядру PostgreSQL + расширение.
Не соглашусь с идеей о падении производительности по мере разработки. Всё-таки у PostgreSQL на современном железе по мере разработки производительность в целом растёт. Это можно проверить. Соберите PostgreSQL 7.4 и запустите pgbench на мощной виртуалке и вы увидите как узкие места, над расшиванием которых сообщество работало десятилетиями, приводят к крайне низкой по современным меркам производительности.
Что касается производительности OrioleDB vs дефолтовый движок PostgreSQL, то OrioleDB сейчас выигрывает за счёт своей архитектуры (https://www.orioledb.com/docs/architecture/overview). При этом остаётся огромный потенциал для оптимизаций в OrioleDB, т.к. туда пока не вложено и десятой доли труда по сравнению с дефолтовым движком PostgreSQL. Поэтому отрыв по прозиводительности в ближайшее время будет только расти.
| | |
| |
| 3.46, Alexander Korotkov (?), 10:53, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Добавлю ещё, что в данном контексте я рассматриваю производительность именно самого табличного движка и непосредственно связанных подсистем (WAL, checkpointer, buffer manager и т.д.)
При этом в PostgreSQL есть ещё много узких мест: протокол, планировщик, экзекьютер и т.д., которые OrioleDB почти никак не затрагивает.
| | |
| 3.50, fuggy (ok), 12:31, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Они не открыли америку. Движок на основе undo logs, уже реализовали несколько лет назад zheap, сразу как только появилась возможность подключать кастомные движки. Есть где-то сравнение что из этого лучше, чтобы сравнивать похожие технологии. Ссылка полезная. Но нужно учитывать что у undo logs есть и свои минусы, что изменение записи требует вставки + перемещения старой версии в лог. В то время как у стандартного движка только вставка новой версии.
| | |
|
|
| 1.28, slew (ok), 15:38, 02/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Наконец-то сделали так, как в оракле было сделано 50 лет назад.
| | |
| |
| 2.29, нах. (?), 15:42, 02/12/2024 [^] [^^] [^^^] [ответить]
| +1 +/– | |
не сделали. Всего лишь бета. Зато - седьмая. Такими темпами успеют к концу света.
| | |
| 2.49, Аноним (47), 12:29, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Оракл нормальным стал только с версии 9. Даже 8-ка была так себе удовольствием. Т.е. с начала 00-вых. Не полвека, а только четверть.
| | |
| 2.52, fuggy (ok), 12:33, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Так а зачем городить велосипед, если можно взять взять тот же бесплатный mysql. Где тоже структура таблицы имеет первичный индекс.
| | |
| |
| 3.59, Аноним (47), 14:46, 03/12/2024 [^] [^^] [^^^] [ответить] | +/– | Это как понять -- структура таблицы имеет первичный индекс Табличка это упорядо... большой текст свёрнут, показать | | |
| |
| 4.70, fuggy (ok), 15:53, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Почему только myisam, innodb тоже, который по сути остался единственным вариантом для acid транзакций. Там каждая таблица кластеризована по первичному индексу. И все остальные вторичные индексы ссылаются на этот индекс.
В отличие от postgresql, где все данные лежат в неупорядоченном массиве. Там кластеризация, это лишь временная операция. А также приходится часто обновлять индексы, из-за обновления строк новыми версиями.
| | |
| |
| 5.76, Аноним (47), 18:04, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ещё раз, таблица эта такая хрень, где есть первая строка, вторая, вторая ниже первой, но выше третьей, и так далее. И это порядок где-то в мета-инфе задан. Вот на листке бумажки ты табличку рисуешь карандашиком, а как ей пользоваться у тебя в социо-культурном коде в мозгах "зашито". Больше никаких таблиц нет. А "кластерная таблица" в МС или в Инно это дерево, а не таблица, в котором данные строк приделаны к листовому уровню. По факту это двунаправленных список.
И не в каких "неупорядоченных" массивах данные не лежат -- таких массивов не бывает, массив это множество, к которому приделали категорию порядка, т.е. упорядочили по определению. Типично данные "табличек"-отношений хранятся в куче.
| | |
| 5.78, Аноним (47), 18:11, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Кластерная таблица очень-очень мутный термин. Потому что в МС кластерная таблица это про хранение данных отношения в структуре битри-индекса, а вот в Оракле кластерная таблица это вообще не про индексы, а про хранение однотипных данных разных отношений в одной куче.
| | |
|
|
|
|
| 1.35, Olololololololo (-), 20:43, 02/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
>прямое связывание страниц в оперативной памяти со страницами в постоянном хранилище
Ну вот это они зря, нужно было всё самим ручками писать, а не ядро использовать и уж тем более не использовать mmap. Это прямой затык. Кто не верит ищите тесты гугле.
| | |
| |
| |
| |
| 4.57, Аноним (47), 14:31, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Хабровая статья, как это часто бывает, перевод продуктивного бреда какого-то очередного шизофреника. Нет никакой проблемы с fsync-ом.
| | |
| |
| 5.65, Olololololololo (-), 15:34, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ждём оттвета Короткова.
Моё личное мнение, что БД должны использовать только direct io беря на себя функции кеша и т.п., если нужна надёжность и производительность.
| | |
|
| 4.73, Olololololololo (-), 16:21, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
И ещё вопросы:
- PostgreSQL использует huge pages, если нет то пробовали ли включать?
- Если пробовали какой результат?
Слышал, что или MariaDB или PerconaDB или т.п. включило huge pages и результат был хуже чем без них.
| | |
| 4.81, Alexander Korotkov (?), 08:11, 04/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
> - А fsync всё ещё используете (навеено этим https://habr.com/ru/articles/472684/)?
> - Не считаете, что использовать fsync в БД это глупо?
Да, fsync используем. Не считаю, что это глупо, но считаю то не оптимально.
К статье на хабре стоит добавить то, чем всё закончилось
https://git.postgresql.org/gitweb/?p=postgresql.git;h=1556cb2fc5c774c3f7390dd6
https://git.postgresql.org/gitweb/?p=postgresql.git;h=9ccdd7f66e3324d2b6d3dec2
> - Не думали использовать, что-то типа io_uring или spdk?
Да, планируем в будущем переходить на более продвинутые решения.
| | |
|
| 3.54, Olololololololo (-), 13:21, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Мы mmap используем только для экспериментального режима хранения данных в persistent memory (проводили эксперименты с Intel Optane).
А это в принципе не важно для чего вы используете. HFT системы, например, не используют mmap т.к. ядро Linux становится тормозом. А ядро вы используете, значит и с optane у вас на нагрузках будут те же самые грабли.
| | |
| |
| 4.80, Alexander Korotkov (?), 08:01, 04/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Как раз таки важно для чего использовать mmap!
Если мапить файл или блочное устройство – то ядро занимается подгрузкой и записью страниц, и происходят тормоза о которых вы говорите.
Если мапить персистентную память, подключенную к шине также как и обычная память, память просто мапится на адресное пространство процесса. И при этом уже во взаимодействии с данной памятью ядро никак не участвует.
Так что mmap mamp'у – рознь :)
| | |
|
| |
| 4.83, Alexander Korotkov (?), 09:00, 04/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Да, OrioleDB написан на C.
Есть низкоуровневая часть кода, связанная с форматом tuples, упаковкой данных на страницы и т.д. Насколько я знаю, эта часть практически везде написана на C.
Есть часть кода, сильно завязанная на внутренние структуры и функции PostgreSQL, которые в свою очередь тоже написаны на C.
Между ними есть небольшая прослойка, которая возможно выиграла бы от Rust. Но не занимались.
| | |
|
|
|
| 1.48, Аноним (47), 12:26, 03/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Прям маркетинговая няшка для утомлённых ораклом. Все приписываемые улучшения улучшения только в сознании дба-неофита. Сплошные разоблачения мифов. Нет вакуума -- ура!!! Счётчик 64 бита -- ура!!! Есть отдельное ТП для undo -- ура!!! Обновления по месту, а не постоянный cow -- ура!!! WAL на уровне строк, а не на уровне кластера целиком -- ура!!! Как-то слишком про желание сделать из одного, что-то совсем другое.
| | |
| |
| 2.55, Olololololololo (-), 13:25, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Обновления по месту, а не постоянный cow -- ура!!!
Мне этот конкрентый момент показался спорным с точки зрения производительности и нагрузки. Нужны тесты. Предполагаю, профита в скорости не будет, а вот падение производительности не исключенно.
| | |
| |
| 3.60, Аноним (47), 14:50, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
>>Обновления по месту, а не постоянный cow -- ура!!!
> Мне этот конкрентый момент показался спорным с точки зрения производительности и нагрузки.
> Нужны тесты. Предполагаю, профита в скорости не будет, а вот падение
> производительности не исключенно.
Самый очевидный профит в том, что замена одной закорючки в строке из десятков или даже сотен полей не приведёт к созданию новой строки. Но модель MVCC отход от принципа всегда insert корёжит радикально.
| | |
| |
| 4.64, Olololololololo (-), 15:30, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Мусье считает, что залочить (используя atomic операции) строку для её обновления это дешевле чем вставить новую? Может тебе мат.часть подучить?
| | |
| |
| 5.68, Аноним (47), 15:44, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Мат. часть чего? Понятия не имею, что в конкретных условиях будет быстрее: найти место под вставку и скопировать или просто по месту, которое уже найдено, что-то поменять. По опыту лишь знаю, что даже при большом внимании к настройке вакуума файлы данных пухнут стремительно и необратимо, это в бд, в которых update-ов кратно больше insert-ов.
| | |
| |
| 6.71, Olololololololo (-), 16:04, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Мат. часть чего?
Процессора, кешей, влияния atomics на кеши, протоколы когерентности кешей и т.п. и само собой каким образом делается обновление/вставка строки по месту. Про лог не упоминаю, ты сам про него пишешь ниже. Чтобы строку заменить/обновить по месту нужно эту строку залочить (у PostgreSQL, наскольку помню, есть такая возможность), а лок делается на атомиках, а чтобы добавить новую версию строки в конец файла БД нужно всего лишь её добавить атомарно залочив в метаданные, к которым нет такого потенциально высокого конкуретного доступа.
Дешевле лочить метаданные (заголовок таблицы) чем лочить строку и это я ещё не говорил про перенос старой строки в лог, про который ты написал ниже.
>Но вот Оракл как-то справляется
Правильнее сказать - PostgreSQL не справляется, но это не значит что подход PostgreSQL в некоторых вопросах хуже чем у Oracle. Вполне может быть, что подход у PostgreSQL правильный, но руки не дошли отполировать.
| | |
| |
| 7.72, Olololololololo (-), 16:10, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
>Дешевле лочить метаданные (заголовок таблицы) чем лочить строку
Дополнение, при условии, что читателей больше чем писателей.
| | |
| 7.74, Аноним (47), 16:49, 03/12/2024 [^] [^^] [^^^] [ответить]
| +/– |
Э, Слон, как и прочие, в случае вставки вставляет не в конец (кого/чего?), а туда, где место есть. Т.е. это не тупая вставка в некий всегда известный заранее "хвост", а поиск куда вснуть в уже распределённом и только, если там нету, то выделить новую страницу, опять же, вопрос где. В общем, операция вставки далеко не факт, что дешевле, корректировки по месту. Хотя для корректировки по месту и надо лочить.
| | |
| 7.84, Alexander Korotkov (?), 09:07, 04/12/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Правильнее сказать - PostgreSQL не справляется, но это не значит что подход PostgreSQL в некоторых вопросах хуже чем у Oracle. Вполне может быть, что подход у PostgreSQL правильный, но руки не дошли отполировать.
Я скорее склонен считать, что дело скорее в подходе PostgreSQL, чем в оптимизациях. Например, вот интересная критика подхода [1] из академических кругов.
О том, что PostgreSQL достаточно отполирован косвенно свидетельствует провал таких оптимизаций как WARM [2]. WARM должен был решить часть проблем MVCC, но породил такое количество архитектурных проблем, что доделать его не получилось
1. https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-
2. https://www.postgresql.org/message-id/flat/CABOikdMNy6yowA%2BwTGK9RVd8iw&
| | |
|
|
| 5.69, Аноним (47), 15:51, 03/12/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
А, понял твой скепсис. Да, такой подход требуют где-то хранить лог (или не лог, а всю строку целиком) изменений для строки. И интуиция подсказывает, что вести такой лог будет недешево. Но вот Оракл как-то справляется. Я тестил ещё 13-тый Слон против 19-го Оракл. Оракл update-ы делает быстрее. Ни на что не претендую, но разница была до 40%. Условия были такие, что в исходно созданных и заполненных табличках кол-во строк не менялось, а менялись только сами строки. За цикл все таблички переписывались полностью. Сначала Слон и Оракл были более-менее равно, но чем больше циклов, тем Слон всё сильнее отставал. Во всех табличках был только один индекс по первичному ключу.
| | |
|
|
|
|
| 1.66, Аноним (47), 15:39, 03/12/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А в чём профит маппить буферы сразу на блоки? Такое больше не надо чекпоинтить? В этом?
| | |
|
