Skip site navigation (1) Skip section navigation (2)

Re: Avoiding bad prepared-statement plans.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Mielke <mark(at)mark(dot)mielke(dot)cc>
Cc: Jeroen Vermeulen <jtv(at)xs4all(dot)nl>, Alex Hunsaker <badalex(at)gmail(dot)com>, Robert Haas <robertmhaas(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:27:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Mark Mielke <mark(at)mark(dot)mielke(dot)cc> writes:
> Will "guessing" at when the user can afford to wait longer improve the 
> situation? Maybe or often, but not always.

There is no way to eliminate "guessing".  The entire point here is that
we don't know whether generating a custom plan will provide a win over
not doing so, until after we've done it (and already taken the planning
time hit).  We could possibly put in heuristic tests based on the
query's use of certain features; but that's still guessing, and would
take nonzero time in itself.

I concur with Jeroen's feeling that going for a simple approach first
is the way to attack this.  We could design and build something vastly
more complex, then find out that it doesn't actually work much better.

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.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-02-26 16:28:39
Subject: Re: ecpg tests broken by pgindent run
Previous:From: Garick HamlinDate: 2010-02-26 16:26:23
Subject: pgbouncer + psql 9.0a4

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group