EleanorОжидаемый комментарий: мол многие люди злоупотребляют хинтами, не умеют "готовить" запросы и т.д.

Не "мол", а да, так и есть! Впрочем, обоснования того, почему проект "не хочет" такие hints, какие обычно используются, на wiki есть (ссылку я давал, кажется).

EleanorХинты, например, полезны для быстрой оценки гипотез: предполагаешь, что в таком варианте план будет эффективнее, и легко заставляешь запрос его использовать без плясок с бубном. А дальше понимаешь, верная была гипотеза или нет, стоит ли тратить время на корректировку запроса уже без использования хинтов.

Если для кого-то проблема заставить запрос использовать какой-то план в тестовой среде --- это "пляски с бубном", то может быть, следует просто этому научиться? Или, например, проблема на самом деле с критериями оценки эффективности или настройками сервера, а вовсе не с конкретным планом?

EleanorК тому же, что мы видим в ближайших планах разработки ? Это же один из видов хинтов, plan guid-ы.

Какое отношение планы Postgres pro (yet another fork) имеют к планам vanilla PostgreSQL? Т.е. это просто мимо.

EleanorPostgres-у по большому счету требуется только щедрое финансирование, множество разработчиков, чтобы копировать наработки лидеров, и постепенно их нагнать.
Сообществу нужно копировать "наработки" так называемых "лидеров" примерно так же, как Python-у (или другому современному языку высокого уровня) нужно копировать "наработки" COBOL-а. Т.е. спасибо, но нет.
Кстати, когда эти упомянутые "лидеры" нагонят PostgreSQL и реализуют десятки features, которые в нём есть?
А то попытки что-то в них разрабатывать иногда начинают напоминать использование ассемблера... в 2018 году!

EleanorПонимаю, разработчики часто относятся к бизнесу со стойким пофигизмом. Это же реальная работа боевой системы.

Что-что, простите? О чём конкретно речь?

EleanorПредставьте, что...

А теперь представьте, что всё, Вами изложенное, можно написать про любую другую СУБД, просто заменив конкретные проблемы на какие-то другие:

Представьте, что система падает.

Руководство получает такое объяснение:
виноват сломавшийся X. Его убрали, теперь всё отлично. Баг странный, потому что разработчики Oracle / MS SQL / DB2 его якобы уже исправили несколько месяцев назад. На тестовой системе не проявился.

Через 2 дня дба снова просит согласовать простой системы. Он подключил какой-то модуль Z, но там оказалась утечка памяти, он заметил поздно, надеется, что система доработает до ночи. И ведь утечку памяти разработчики там уже исправили, не понятно, это та же или другая.

Снова падает система, дба начинают скрывать сбои, руководство нервничает, потому что у них уже не выполняется SLA, и могут разорвать договор. Начинает думать, что ничто не обходится так дорого, как платные вещи.

И хорошо, если есть возможность проработать в таком режиме пол года, собрать все грабли, запомнить о них, и больше не использовать неработающие вещи.

Т.е. мы тут прослушали типичный FUD, мне кажется.

Eleanor
Субд, у которых есть развитая система хинтов, очевидно, имеют такие же принципы :
"Внимание!
Так как оптимизатор запросов SQL Server обычно выбирает наилучший план выполнения для запроса, рекомендуется использовать указания <join_hint>, <query_hint> и <table_hint> в последнюю очередь и только опытным разработчикам и администраторам баз данных."
Что как бы намекает нам, что "развитая система хинтов" --- это legacy (с тех времён, когда оптимизатор запросов недостаточно часто "выбирал наилучший план выполнения для запроса"), использование которого не рекомендуется. ;)
И основная причина того, что она там есть (и будет) теперь --- backward compatibility.
Подобных "features" наверняка немало во всех современных СУБД, включая PostgreSQL, кстати.

EleanorДа, здесь это уже указывали: интернет магазин, или сайт визитка фирмы, или форум такой субд вполне по силам.

Не вижу никакой логической связи... т.е. это опять похоже на FUD.
Или же Вы утверждаете, что все БД, которые "круче" (что бы это ни значило ;) ), чем вышеуказанные, просто обязаны нарушать основные принципы проектирования и реализации OLTP?

EleanorКак-то натыкалась на статью, где основную массу субд отделяли от развитых именно по наличию параллелизма, как сложной в реализации фичи.
И что? Параллелизм --- это DWH feature, и в этой области PostgreSQL ещё есть куда развиваться, конечно.
Кстати, использовать для масштабного / сложного DWH СУБД общего назначения, наверное, не стоит (если считать деньги, конечно).

EleanorВидите результаты Postgres на www.tpc.org? Нет.

Сейчас --- не вижу.
Кстати, те, кто непременно хочет их там увидеть, не разбираются ни в opensource development, ни в PostgreSQL, ни в тестах TPC.
Вы понимаете, что PostgreSQL --- это проект , а не чей-то продукт ?!
Вы думаете, каждый член сообщества PostgreSQL должен заплатить из личных средств за эту бесполезную (для них, конкретных людей) рекламу?

EleanorОправдывают они это очень незамысловато: https://wiki.postgresql.org/wiki/TPC-H

Не "оправдывают", а объясняют.
Не могли бы Вы засунуть свои попытки применения демагогических приёмов туда, откуда Вы их взяли?
И воздержаться от таковых в дальнейшем...

EleanorТест TPC они попытались пройти уже давно, лет 10 назад. Больше не пытаются.

Тесты TPC не "проходят", а просто выполняют и публикуют результаты.
И не "они", а какая-то компания "тестировала" PostgreSQL (в рекламных целях, вероятно).

EleanorПока кроме размытых рассуждений, а-ля: Postgres лучше лидеров, потому что за лицензию платить не надо , и за это его много кто использует, здесь ничего не было.
Кто же спорит - это очень большой плюс.
Тут (в форумах, в смысле) много чего было, кроме этого, поищите.

SiemarglPgSQLanonymous3, лучше не пиши. Бреда и без тебя достаточно.Лучше не хами, а напиши конкретно, что из написанного мной --- бред.

Andy_OLAPКак грубо. И в адрес дамы. Ай-яй-яй, я таки Вас не узнаю - такой приличный молодой человек и такой выпад.
Ах да, к "дамам" же применимы другие моральные критерии, они же "выше" людей, как это я забыл... ;(
Вы, кстати, могли бы что-нибудь пояснить по своим предыдущим высказываниям (про MVCC и упреждающее чтение крупными блоками)?