From: | Shaun Thomas <sthomas(at)optionshouse(dot)com> |
---|---|
To: | Craig James <cjames(at)emolecules(dot)com>, Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
Cc: | Stefan Keller <sfkeller(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Getting query plan alternatives from query planner? |
Date: | 2014-03-21 19:43:41 |
Message-ID: | 532C966D.2080500@optionshouse.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 03/21/2014 08:34 AM, Craig James wrote:
> There have been many discussions about adding hints to Postgres over the
> years. All have been firmly rejected by the Postgres developers, with
> well-argued reasons. Search the archives to learn more about this topic.
While that's true, and I agree with the sentiment, it could also be
argued that what we have now is actually worse than hints.
I've been bitten several times by wrong query plans. The cause is
usually due to bad correlation estimates or edge-cases due to incomplete
stats. Aside from cranking default_statistics_target up to 10,000, 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?
Well... they're worse, really. Hints can be deprecated, disabled in
configs, or ignored in extreme cases. Optimization fences are truly
forever. Unless of course they're removed. In which case, a bunch of
queries that exploited them will suddenly perform a whole lot worse,
causing organizations to delay upgrading PostgreSQL.
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-676-8870
sthomas(at)optionshouse(dot)com
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
From | Date | Subject | |
---|---|---|---|
Next Message | Erik van Zijst | 2014-03-22 00:59:19 | Suboptimal query plan when using expensive BCRYPT functions |
Previous Message | Claudio Freire | 2014-03-21 19:04:06 | Re: Connection pooling - Number of connections |