From: | Csaba Nagy <nagy(at)ecircle-ag(dot)com> |
---|---|
To: | PFC <lists(at)peufeu(dot)com> |
Cc: | Dawid Kuroczko <qnex42(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Cached Query Plans (was: global prepared statements) |
Date: | 2008-04-14 08:34:38 |
Message-ID: | 1208162078.8259.259.camel@PCD12478 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> The hairiness is in the plan dependence (or independence) on parameter
> values, ideally we only want to cache plans that would be good for all
> parameter values, only the user knows that precisely. Although it could be
> possible to examine the column histograms...
If cached plans would be implemented, the dependence on parameter values
could be solved too: use special "fork" nodes in the plan which execute
different sub-plans depending on special parameter values/ranges,
possibly looking up the stats at runtime, so that the plan is in a
compiled state with the "decision points" wired in.
This of course would mean a lot heavier planning and possibly a lot
bigger plans, but you could afford that if you cache the plan. You could
even have a special command to plan a query this way.
Cheers,
Csaba.
From | Date | Subject | |
---|---|---|---|
Next Message | PFC | 2008-04-14 12:22:29 | Re: Cached Query Plans (was: global prepared statements) |
Previous Message | Pavel Stehule | 2008-04-14 06:15:38 | proposal: Additional parameters for RAISE statement |