Mark Kirkwood <mark.kirkwood@xxxxxxxxxxxxxxx> writes: > Unfortunately a trigger will not really do the job - analyze ignores in > progress rows (unless they were added by the current transaction), and > then the changes made by analyze are not seen by any other sessions. So > no changes to plans until the entire INSERT is complete and COMMIT > happens (which could be a while - too long in our case). I'm not sure I believe the thesis that plans won't change at all. The planner will notice that the physical size of the table is growing. That may not be enough, if the table-contents statistics are missing or completely unreflective of reality, but it's something. It is true that *already cached* plans won't change until after an ANALYZE is done (the key point there being that ANALYZE sends out a shared-inval message to force replanning of plans for the table). Conceivably you could issue concurrent ANALYZEs occasionally while the INSERT is running, not so much to update the stats --- because they wouldn't --- as to force cached-plan invalidation. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
