On 2017-03-07 21:03:53 -0500, Robert Haas wrote:
> On Tue, Mar 7, 2017 at 4:26 PM, Stephen Frost <sfrost@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
