Re: Cached Query Plans (was: global prepared statements) - Mailing list pgsql-hackers

From Csaba Nagy
Subject Re: Cached Query Plans (was: global prepared statements)
Date
Msg-id 1208182832.8259.284.camel@PCD12478
Whole thread Raw
In response to Re: Cached Query Plans (was: global prepared statements)  (Csaba Nagy <nagy@ecircle-ag.com>)
Responses Re: Cached Query Plans  (Mark Mielke <mark@mark.mielke.cc>)
List pgsql-hackers
> ... or plan the query with the actual parameter value you get, and also
> record the range of the parameter values you expect the plan to be valid
> for. If at execution time the parameter happens to be out of that range,
> replan, and possibly add new sublpan covering the extra range. This
> could still work with prepared queries (where you don't get any
> parameter values to start with) by estimating the most probable
> parameter range (whatever that could mean), and planning for that.

Another thought: if the cached plans get their own table (as it was
suggested) then you could also start gathering parameter range
statistics meaningfully... and on the next replan you know what to
optimize your planning efforts for.

Cheers,
Csaba.




pgsql-hackers by date:

Previous
From: Csaba Nagy
Date:
Subject: Re: Cached Query Plans (was: global prepared statements)
Next
From: Tom Lane
Date:
Subject: Race conditions in relcache load (again)