On 2017-03-07 21:03:53 -0500, Robert Haas wrote: > 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.
Indeed. I wonder however, if careful snapshot managment couldn't solve this as well. I have *not* thought a lot about this, but afaics we can easily prevent all-visible from being set in cases it'd bother us by having an "appropriate" xmin / registered snapshot. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
