From: | "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Csaba Nagy" <nagy(at)ecircle-ag(dot)com> |
Cc: | "postgres hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Prepared statements considered harmful |
Date: | 2006-08-31 13:24:47 |
Message-ID: | E1539E0ED7043848906A8FF995BDA579014DBDAF@m0143.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > How about "prepared" means really "prepared"... in the sense of
> > parsed, analyzed all sensible plans, and save a meta-plan which
based
> > on current statistics and parameter values chooses one of the
> > considered (and cached) plans ?
>
> I don't think this could solve one particularly frequent
> problem which is that pattern matching queries don't get
> along with prepared plans if the search pattern isn't known
> at planning time.
I think what we would actually want is knowledge about how
much difference different parameters actually make in plan decision.
(the stats show an even distribution and join correlation)
Then we could prepare the plan when there is not much difference
and postpone planning until we know the parameters when the difference
is big.
OLTP workload typically benefits from prepared plans, and the one plan
is good
for all possible inputs, so imho we cannot just assume all plans need
replanning
for different parameters.
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2006-08-31 13:25:32 | Re: Prepared statements considered harmful |
Previous Message | Peter Eisentraut | 2006-08-31 13:19:22 | Re: Prepared statements considered harmful |