From: | "Jim C(dot) Nasby" <jim(at)nasby(dot)net> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Phil Frost <indigo(at)bitglue(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Prepared statements considered harmful |
Date: | 2006-09-02 21:49:58 |
Message-ID: | 20060902214957.GK84229@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 01, 2006 at 04:14:32PM +0100, Gregory Stark wrote:
> >> Interesting thought. It might be worth trying. But my big question: is
> >> all this testing and counting actually going to be faster than just
> >> replanning? Postgresql's planner is not that slow.
> >
> > In the best case (which of course would have to be very frequent for any
> > of this to matter in the first place) it's mainly just a short loop
> > comparing the call's parameter values to their counterparts stored with
> > the plan and update those two-bit confidence counters. You wouldn't
> > *believe* how simple you have to keep these things in processor
> > architecture. :-)
>
> I think the slow part is trying to figure out whether to count the current
> call as a hit or a miss. How do you determine whether the plan you're running
> is the best plan without replanning the query?
Simply looking at estimated row counts/cost versus what actually
happened would probably suffice. It'd at least be a great start.
--
Jim C. Nasby, Database Architect jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-09-02 21:59:36 | Re: Coding style for emacs |
Previous Message | Ron Johnson | 2006-09-02 21:30:40 | Re: Thought provoking piece on NetBSD |