From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Transient plans versus the SPI API |
Date: | 2011-08-06 18:29:56 |
Message-ID: | m262majsuz.fsf@2ndQuadrant.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> I think we'll be a lot better off with the framework discussed last
> year: build a generic plan, as well as custom plans for the first few
> sets of parameter values, and then observe whether there's a significant
> reduction in estimated costs for the custom plans.
Another way here would be to cache more than a single plan and to keep
execution time samples or some other relevant runtime characteristics.
Then what we need would be a way to switch from a plan to another at run
time on some conditions, like realizing that the reason why the planner
thought a nestloop would be perfect is obviously wrong, or maybe just
based on runtime characteristics.
> But in any case, it's way premature to be debating this until we have
> the infrastructure in which we can experiment with different policies.
That too.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Hunsaker | 2011-08-06 18:37:28 | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https |
Previous Message | Dimitri Fontaine | 2011-08-06 18:16:13 | Re: mosbench revisited |