da...@lang.hm writes:
> the poster who started this thread had a query where the parsing phase
> took significantly longer than the planning stage.
That was an anecdote utterly unsupported by evidence.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-
On Thu, 1 Jan 2009, Guillaume Smet wrote:
On Thu, Jan 1, 2009 at 9:24 PM, wrote:
forgive my ignorance here, but if it's unnamed how can you reference it
later to take advantage of the parsing?
You can't. That's what unnamed prepared statements are for.
It's not obvious to me that the parsi
On Thu, Jan 1, 2009 at 9:24 PM, wrote:
> forgive my ignorance here, but if it's unnamed how can you reference it
> later to take advantage of the parsing?
You can't. That's what unnamed prepared statements are for.
It's not obvious to me that the parsing phase is worth any "caching".
>From my e
On Thu, 1 Jan 2009, Guillaume Smet wrote:
On Wed, Dec 31, 2008 at 5:01 PM, Alvaro Herrera
wrote:
I think it has been shown enough times that the performance drop caused
by a worse plan can be orders of magnitudes worse than what's gained by
producing the plan only once. It does not seem a bad
On Wed, Dec 31, 2008 at 5:01 PM, Alvaro Herrera
wrote:
> I think it has been shown enough times that the performance drop caused
> by a worse plan can be orders of magnitudes worse than what's gained by
> producing the plan only once. It does not seem a bad idea to provide a
> way to carry out on
On Wed, Dec 31, 2008 at 11:01 AM, Alvaro Herrera
wrote:
>> The point of a prepared statement IMHO is to do the planning only once.
>> There's necessarily a tradeoff between that and having a plan that's
>> perfectly adapted to specific parameter values.
>
> I think it has been shown enough times t
