pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Eric Schwarzenbach <subscriber@blackbrook.org>
To: pgsql-performance@postgresql.org
Subject: Re: Getting query plan alternatives from query planner?
Date: Mon, 14 Apr 2014 10:59:52 -0400
Message-ID: <534BF7E8.4090008@blackbrook.org> (raw)
In-Reply-To: <1397486357.89780.YahooMailBasic@web122305.mail.ne1.yahoo.com>
References: <1397486357.89780.YahooMailBasic@web122305.mail.ne1.yahoo.com>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

I don't know how anyone else feels about this, as I don't think I've 
seen this ever suggested, but my ideal would be a way to configure the 
database to recognize specific queries and to have a way of influencing 
its plan choice for that query. I'm intentionally wording that last part 
vaguely, as I'm not sure what would be best or practical there. Ideally, 
perhaps, would be to be able to store a particular plan for that query 
and have it always use it.

I don't want either hints OR fence distortions in my application code, 
which might have to work with different versions of PostgreSQL with 
different optimization characteristics, different servers with different 
performance characteristics, or even different database products 
entirely. A solution to a server-side problem should live on the server 
not on the client. That's why I've always preferred PostgeSQL's server 
settings for tweaking the optimizer to the hints offered by other products.

On 4/14/2014 10:39 AM, Kevin Grittner wrote:
> 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
>
>
>



-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance



view thread (12+ messages)  latest in thread

Message-ID: <534BF7E8.4090008@blackbrook.org>
Permalink:  ../534BF7E8.4090008@blackbrook.org/
Also on:    postgresql.org/message-id/534BF7E8.4090008@blackbrook.org

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: subscriber@blackbrook.org
  Subject: Re: Getting query plan alternatives from query planner?
  In-Reply-To: <534BF7E8.4090008@blackbrook.org>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox