Re: Transient plans versus the SPI API

Tom Lane wrote:
> > Note that the SPI functions are more or less directly exposed in PL/Perl
> > and PL/Python, and there are a number of existing idioms there that make
> > use of prepared plans. Changing the semantics of those functions might
> > upset a lot of code.
>
> Right, but by the same token, if we don't change the default behavior,
> there is going to be a heck of a lot of code requiring manual adjustment
> before it can make use of the (hoped-to-be) improvements. To me it
> makes more sense to change the default and then provide ways for people
> to lock down the behavior if the heuristic doesn't work for them.

Agreed. I think the big sticking point is that without logic on how the
replanning will happen, users are having to guess how much impact this
new default behavior will have. I also agree that this will harm some
uses but improve a larger pool of users. Remember, the people on this
email list are probably using this feature in a much more sophisticated
way than the average user.

Also, there is a TODO idea that the results found by executing the query
(e.g. number of rows returned at each stage) could be fed back and
affect the replanning of queries.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +