Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC

Поиск

Список

Период

Сортировка

От	Pavan Deolasee
Тема	Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC
Дата	8 марта 2017 г. 08:42:41
Msg-id	CABOikdN_-75G5y+9-HBzRyChAeUXRNJA8EpnbybaRiLDy10kDw@mail.gmail.com обсуждение исходный текст
Ответ на	Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC (Robert Haas <robertmhaas@gmail.com>)
Ответы	Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC (Stephen Frost <sfrost@snowman.net>) Re: [HACKERS] Skip all-visible pages during second HeapScan of CIC (David Steele <david@pgmasters.net>)
Список	pgsql-hackers

Дерево обсуждения

On Wed, Mar 8, 2017 at 7:33 AM, Robert Haas <robertmhaas@gmail.com> 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.

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.

Thanks,

Pavan