Date: Fri, 3 Nov 2017 02:28:47 -0700 (MST)
From: Thomas Kellerer <spam_eater@gmx.net>
To: pgsql-performance@postgresql.org
Message-ID: <1509701327868-0.post@n3.nabble.com>
In-Reply-To: <1509611428.3268.5.camel@cybertec.at>
References: <f1b85c37-e4b5-c158-5f67-a780a2191e20@gusw.net>
 <1509611428.3268.5.camel@cybertec.at>
Subject: Re: OLAP/reporting queries fall into nested loops over seq scans or
 other horrible planner choices
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

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