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.
Fair point. I'm not going to "persist" with the idea too long. It seemed like a good, low-risk feature to me which can benefit certain use cases quite reasonably. It's not uncommon to create indexes (or reindex existing indexes to remove index bloats) on extremely large tables and avoiding a second heap scan can hugely benefit such cases. Holding up the patch for something for which we don't even have a proposal yet seemed a bit strange at first, but I see the point.
Anyways, for a recently vacuumed table of twice the size of RAM and on a machine with SSDs, the patched CIC version runs about 25% faster. That's probably the best case scenario.
I also realised that I'd attached a slightly older version of the patch. So new version attached, but I'll remove the patch from CF if I don't see any more votes in favour of the patch.
