Andres Freund <and...@2ndquadrant.com> wrote: > We can play cute tricks akin to what CREATE INDEX CONCURRENTLY currently > does, i.e. wait for all other relations that could have possibly seen > the old relfilenode (they must have at least a share lock on the > relation) before dropping the actual storage. > > The reason we cannot currently do that in most scenarios is that we > cannot perform transactional/mvcc updates of non-exclusively locked > objects due to the SnapshotNow problems of seeing multiple or no > versions of a row during a single scan.
Not only would that be slower than the submitted patch in cases where only a few rows differ, but it could be waiting to swap in that new heap for an unbounded amount of time. I think the current patch will "play nicer" with incremental maintenance than what you suggest here. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
