Jeff Davis <pg...@j-davis.com> writes: > On Wed, 2009-02-04 at 14:40 -0500, Robert Haas wrote: >> Well, there's nothing to force that plan to be invalidated when the >> state of the pending list changes, is there?
> Would it be unreasonable to invalidate cached plans during the pending > list cleanup? If the pending list cleanup is done by VACUUM then such an invalidation already happens (VACUUM forces it after updating pg_class.reltuples/ relpages). What's bothering me is the lack of any reasonable mechanism for invalidating plans in the other direction, ie when the list grows past the threshold where this code wants to turn off indexscans. Since the threshold depends on parameters that can vary across sessions, you'd more or less have to send a global invalidation after every addition to the list, in case that addition put it over the threshold in some other session's view. That's unreasonably often, in my book. Also, as mentioned earlier, I'm pretty down on the idea of a threshold where indexscans suddenly turn off entirely; that's not my idea of how the planner ought to work. But the real bottom line is: if autovacuum is working properly, it should clean up the index before the list ever gets to the point where it'd be sane to turn off indexscans. So I don't see why we need to hack the planner for this at all. If any hacking is needed, it should be in the direction of making sure autovacuum puts sufficient priority on this task. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers