Re: Automatic function replanning
От | Christopher Browne |
---|---|
Тема | Re: Automatic function replanning |
Дата | |
Msg-id | m3vexn0w5e.fsf@mobile.int.cbbrowne.com обсуждение исходный текст |
Ответ на | Re: Automatic function replanning ("Jim C. Nasby" <jnasby@pervasive.com>) |
Ответы |
Re: Automatic function replanning
|
Список | pgsql-hackers |
> Lukas Smith <mls@pooteeweet.org> writes: >> Bruce Momjian wrote: >>> * Flush cached query plans when the dependent objects change, >>> when the cardinality of parameters changes dramatically, or >>> when new ANALYZE statistics are available > >> Wouldn't it also make sense to flush a cached query plan when after >> execution it is determined that one or more assumptions that the cached >> query plan was based on was found to be off? > > Not unless you do something that would cause the planner to make > different choices next time. (Such as changing the ANALYZE statistics, > perhaps.) The TODO item is OK as stated, it's just talking about > mechanism and not the things that might trigger the mechanism. A mechanism might be to bump up the stats stored for pg_autovacuum, which would encourage a table to be re-ANALYZEd. That may not immediately change ANALYZE statistics, but it's something... Even if there is NO feedback mechanism on statistics, if we know the plan was pretty bad, it is surely at least *a* feedback to invalidate the plan. -- (reverse (concatenate 'string "moc.liamg" "@" "enworbbc")) http://cbbrowne.com/info/slony.html ``Lisp has jokingly been called "the most intelligent way to misuse a computer". I think that description is a great compliment because it transmits the full flavor of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts.'' -- "The Humble Programmer", E. Dijkstra, CACM, vol. 15, n. 10, 1972
В списке pgsql-hackers по дате отправления: