On Tue, Mar 7, 2017 at 9:12 PM, Andres Freund <and...@anarazel.de> wrote: > 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.
Yeah, but that's a tax on the whole system. -- 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