From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Optimizing prepared statements |
Date: | 2006-09-03 14:52:21 |
Message-ID: | 87k64lvw7u.fsf@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Jeroen T. Vermeulen" <jtv(at)xs4all(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2006-09-03 15:01:37 | Re: Postgres tracking - the pgtrack project |
Previous Message | Jeroen T. Vermeulen | 2006-09-03 14:27:47 | Re: Optimizing prepared statements |