Re: Getting query plan alternatives from query planner? - Mailing list pgsql-performance

From Kevin Grittner
Subject Re: Getting query plan alternatives from query planner?
Date
Msg-id 1397486357.89780.YahooMailBasic@web122305.mail.ne1.yahoo.com
Whole thread Raw
In response to Re: Getting query plan alternatives from query planner?  (Shaun Thomas <sthomas@optionshouse.com>)
Responses Re: Getting query plan alternatives from query planner?  (Eric Schwarzenbach <subscriber@blackbrook.org>)
List pgsql-performance
Shaun Thomas <sthomas@optionshouse.com> wrote:

> these issues tend to get solved through optimization fences.
> Reorganize a query into a CTE, or use the (gross) OFFSET 0 trick.
> How are these nothing other than unofficial hints?

Yeah, the cognitive dissonance levels get pretty high around this
issue.  Some of the same people who argue strenuously against
adding hints about what plan should be chosen also argue against
having clearly equivalent queries optimize to the same plan because
they find the fact that they don't useful for coercing a decent
plan sometimes.  That amounts to a hint, but obscure and
undocumented.  (The OP may be wondering what this "OFFSET 0 trick"
is, and how he can use it.)

> Well... they're worse, really. Hints can be deprecated, disabled
> in configs, or ignored in extreme cases. Optimization fences are
> truly forever.

+1

With explicit, documented hints, one could search for hints of a
particular type should the optimizer improve to the point where
they are no longer needed.  It is harder to do that with subtle
differences in syntax choice.  Figuring out which CTEs or LIMITs
were chosen because they caused optimization barriers rather than
for their semantic merit takes some effort.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-performance by date:

Previous
From: Ryan Johnson
Date:
Subject: Re: SSI slows down over time
Next
From: Eric Schwarzenbach
Date:
Subject: Re: Getting query plan alternatives from query planner?