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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
