Re: Optimizing prepared statements - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Optimizing prepared statements
Date
Msg-id 87k64lvw7u.fsf@enterprisedb.com
Whole thread Raw
In response to Re: Optimizing prepared statements  ("Jeroen T. Vermeulen" <jtv@xs4all.nl>)
Responses Re: Optimizing prepared statements  ("Jeroen T. Vermeulen" <jtv@xs4all.nl>)
List pgsql-hackers
"Jeroen T. Vermeulen" <jtv@xs4all.nl> writes:

> On Sun, September 3, 2006 18:41, Gregory Stark wrote:
>
>> I'm confused, what exactly are you trying to predict? Whether each
>> parameter
>> will be some cached value? Or whether the cached plan was correct?
>
> That's described in more detail in a separate thread ("prepared statements
> considered harmful").  In a nutshell, the algorithm detects pseudoconstant
> parameters to prepared statements, and keeps a small set of different
> plans optimized for recurring combinations of constants.

I read that but apparently I misunderstood it since it would not have been
doable the way I understood it. I thought you wanted the predictor bits to
correspond to particular plans. If a plan was "wrong" then you marked it as a
bad guess. I don't think that can be made to work though for the reasons I
stated then.

But if you have something working clearly that's not what you're doing. So
what are you doing? Storing up a list of arguments seen for each parameter
when executed and use the predictor bits to determine if any of those
arguments are constants? Storing up a list of selectivity estimates?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: "Jeroen T. Vermeulen"
Date:
Subject: Re: Optimizing prepared statements
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Postgres tracking - the pgtrack project