| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Mark Mielke <mark(at)mark(dot)mielke(dot)cc>, Jeroen Vermeulen <jtv(at)xs4all(dot)nl>, Alex Hunsaker <badalex(at)gmail(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Bart Samwel <bart(at)samwel(dot)tk>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Avoiding bad prepared-statement plans. |
| Date: | 2010-02-26 16:54:10 |
| Message-ID: | 603c8f071002260854v69716cfdw5f28cc76a167d0b6@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Feb 26, 2010 at 11:27 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Also, I think there is a lot of confusion here over two different
> issues: generic plan versus parameter-specific plan, and bad planner
> estimates leading to a wrong plan choice. While the latter is certainly
> an issue sometimes, there is no reason to believe that it affects
> prepared statements worse than non-prepared ones. So I think that
> designing a fix for prepared statements on the assumption that you can't
> trust the planner's estimates is solving the wrong problem.
The two issues seem intimately connected to me. Of course, estimates
can be inaccurate for many reasons, but ONE of those reasons is that
the planner is optimizing for an unknown parameter value which has
very different distribution from the actually supplied value.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Boszormenyi Zoltan | 2010-02-26 16:57:18 | Re: ecpg tests broken by pgindent run |
| Previous Message | Robert Haas | 2010-02-26 16:51:53 | Re: Avoiding bad prepared-statement plans. |