Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices

From: Thomas Kellerer <spam_eater(at)gmx(dot)net>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
Date: 2017-11-03 09:28:47
Message-ID: 1509701327868-0.post@n3.nabble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Adam Brusselback 2017-11-03 12:07:13 Re: Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices
Previous Message Laurenz Albe 2017-11-03 08:01:52 Re: OLAP/reporting queries fall into nested loops over seq scans or other horrible planner choices