Исправление borisych, (текущая версия) :
Ну и разработчики Postgres не скрывают ничего в документации, то есть, нет такого, чтобы в документации было заявлено про глобальный индекс, а в реальности его нет или он не работает.
я в документации как-то не смог найти утверждения, что фича абсолютно бесполезна и не стоит ее использовать. К слову, в документации также нет текста из: https://wiki.postgresql.org/wiki/Don't_Do_This
вообще очень ограниченный механизм
хорошо, продолжаем про секционирование. Вопрос: сколько строк с колонками типа bytea можно хранить в таблице? Ответ: значительно меньше чем хотелось бы, bytea хранится в TOAST, у которого идентификатором служит oid, он же unsigned int, т.е. даже в теории ограничение сверху - 4 миллиарда, что, нужно сказать, даже 10 лет назад было не чтобы очень много, но (!) мы же в базу не только вставляем строки, но еще и обновляем и удаляем их, и, о боже, иногда откатываем транзакции, поэтому счетчик TOAST расходуется значительно быстрее чем того хотелось бы. Здесь непонятно, что мешает разработчикам переделать этот oid с unsigned int на unsigned long, однако конкретно в этой ситуации в определенных случаях использование секционирования несомненно бы помогло (исключительно как maintenance история, как принято в других СУБД), но, увы, не работает как того хотелось бы. Таким образом, можно смело утверждать, что хранение в этой СУБД данных типа blob (да и вообще длинных строк, а сейчас пошла мода JSON хранить), довольно сильно ограничено, другими словами не работает (и не нужно здесь про «вы неправильно используете нашу распрекрасную СУБД»).
Кстати, про JSON: а оно умеет делать patch, как того ожидает пользователь этой распрекрасной СУБД или-таки полностью его перезаписывает не смотря на конкурирующие изменения? А то, помнится все несказанно радовались, что постгрес работает быстрее монги с JSON, а вот про обыденные вещи как-то забыли.
А как в постгресе обстоят дела и Direct IO и Async IO? Все также из кешей ФС данные дергает, да? Вот в MySQL, внезапно, оно-таки есть: https://dev.mysql.com/doc/refman/8.0/en/innodb-linux-native-aio.html
Исходная версия borisych, :
Ну и разработчики Postgres не скрывают ничего в документации, то есть, нет такого, чтобы в документации было заявлено про глобальный индекс, а в реальности его нет или он не работает.
я в документации как-то не смог найти утверждения, что фича абсолютно бесполезна и не стоит ее использовать. К слову, в документации также нет текста из: https://wiki.postgresql.org/wiki/Don't_Do_This
вообще очень ограниченный механизм
хорошо, продолжаем про секционирование. Вопрос: сколько строк с колонками типа bytea можно хранить в таблице? Ответ: значительно меньше чем хотелось бы, bytea хранится в TOAST, у которого идентификатором служит oid, он же unsigned int, т.е. даже в теории ограничение сверху - 4 миллиарда, что, нужно сказать, даже 10 лет назад было не чтобы очень много, но (!) мы же в базу не только вставляем строки, но еще и обновляем и удаляем их, и, о боже, иногда откатываем транзакции, поэтому счетчик TOAST расходуется значительно быстрее чем того хотелось бы. Здесь непонятно, что мешает разработчикам переделать этот oid с unsigned int на unsigned long, однако конкретно в этой ситуации в определенных случаях использование секционирования несомненно бы помогло (исключительно как maintenance история, как принято в других СУБД), но, увы, не работает как того хотелось бы. Таким образом, можно смело утверждать, что хранение в этой СУБД данных типа blob (да и вообще длинных строк, а сейчас пошла мода JSON хранить), довольно сильно ограничено, другими словами не работает (и не нужно здесь про «вы неправильно используете нашу распрекрасную СУБД»).
Кстати, про JSON: а оно умеет делать patch, как того ожидает пользователь этой распрекрасной СУБД или-таки полностью его перезаписывает не смотря на конкурирующие изменения? А то, помнится все несказанно радовались, что постгрес работает быстрее монги с JSON, а вот про обыденные вещи как-то забыли.