Re: Avoiding bad prepared-statement plans. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Avoiding bad prepared-statement plans.
Date
Msg-id 28767.1267201631@sss.pgh.pa.us
Whole thread Raw
In response to Re: Avoiding bad prepared-statement plans.  (Mark Mielke <mark@mark.mielke.cc>)
Responses Re: Avoiding bad prepared-statement plans.  (Robert Haas <robertmhaas@gmail.com>)
Re: Avoiding bad prepared-statement plans.  (Mark Mielke <mark@mark.mielke.cc>)
List pgsql-hackers
Mark Mielke <mark@mark.mielke.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: NaN/Inf fix for ECPG
Next
From: Bruce Momjian
Date:
Subject: Re: ecpg tests broken by pgindent run