[PERFORM] Re: OLAP/reporting queries fall into nested loops over seq scans orother horrible planner choices
От | Thomas Kellerer |
---|---|
Тема | [PERFORM] Re: OLAP/reporting queries fall into nested loops over seq scans orother horrible planner choices |
Дата | |
Msg-id | 1509701327868-0.post@n3.nabble.com обсуждение исходный текст |
Ответ на | Re: [PERFORM] OLAP/reporting queries fall into nested loops overseq scans or other horrible planner choices (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: [PERFORM] Re: OLAP/reporting queries fall into nested loops overseq scans or other horrible planner choices
|
Список | pgsql-performance |
Laurenz Albe schrieb am 02.11.2017 um 09:30: > Finally, even though the official line of PostgreSQL is to *not* have > query hints, and for a number of good reasons, this is far from being > an unanimous decision. The scales may tip at some point, though I > personally hope that this point is not too close. I also think that hints are not the right way to solve problems like that. I do like Oracle's approach with SQL profiles, where you can force the optimizer to try harder to find a good execution plan. I _think_ it even runs the statement with multiple plans and compares the expected outcome with the actual values. Once a better plan is found that plan can be attached to that query and the planner will use that plan with subsequent executions. This however requires a much bigger infrastructure then simple hints. (Unrelated, but: maybe a compromise of the never-ending "hints vs. no hints" discussion would be, to think about integrating the existing "pg_hint_plan" as a standard contrib module) Thomas -- Sent from: http://www.postgresql-archive.org/PostgreSQL-performance-f2050081.html -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
В списке pgsql-performance по дате отправления: