| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | david(at)lang(dot)hm |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Scott Carey <scott(at)richrelevance(dot)com>, bricklen <bricklen(at)gmail(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, "pgsql-performance\(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Poor plan choice in prepared statement |
| Date: | 2008-12-31 04:23:41 |
| Message-ID: | 877i5hotv6.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
david(at)lang(dot)hm writes:
> since there is not a pre-parsed interface for queries, it may make sense to
> setup a way to have the query pre-parsed, but not pre-planned for cases like
> this.
What would be more interesting would be to have plans that take into account
the outlier values and have alternative plans for those values.
One aspect that hasn't been discussed here is whether it's only certain
outlier arguments that cause Postgres to choose the poor plan for you or
whether it always chooses it for all the sets of arguments you actually use.
If it's the former then it's possible you're only being bitten if the first
time you prepare the query happens to have one of these outlier set of
parameters. I forget what version this went in but I think it was before 8.2
that Postgres started using the first set of arguments seen to plan the query.
This is usually an improvement over just guessing but if that first set is
unusual it could lead to strange results.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume Smet | 2008-12-31 09:12:47 | Re: Poor plan choice in prepared statement |
| Previous Message | david | 2008-12-31 00:19:01 | Re: Poor plan choice in prepared statement |