Re: Optimizing prepared statements

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

In response to

Responses

Browse pgsql-hackers by date

  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