On Tue, Mar 7, 2017 at 4:26 PM, Stephen Frost <sfr...@snowman.net> wrote: > Right, that's what I thought he was getting at and my general thinking > was that we would need a way to discover if a CIC is ongoing on the > relation and therefore heap_page_prune(), or anything else, would know > that it can't twiddle the bits in the VM due to the ongoing CIC. > Perhaps a lock isn't the right answer there, but it would have to be > some kind of cross-process communication that operates at a relation > level..
Well, I guess that's one option. I lean toward the position already taken by Andres and Peter, namely, that it's probably not a great idea to pursue this optimization. I'm not totally dead-set on that position, but it doesn't seem likely that we can add material synchronization overhead to heap_page_prune(), and I'd rather maintain the option to set visibility map bits in more places in the future than give up that opportunity by optimizing CIC now. It's nice for CIC to be fast, but setting all visible bits more aggressively sounds nicer. -- Robert Haas 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
