Re: [PoC] Improve dead tuple storage for lazy vacuum - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [PoC] Improve dead tuple storage for lazy vacuum
Date
Msg-id CAD21AoCWc6msndJixhj9X+pwM5u12=KgQxyKM+3bh9PXSD-0ug@mail.gmail.com
Whole thread Raw
In response to Re: [PoC] Improve dead tuple storage for lazy vacuum  (Hannu Krosing <hannuk@google.com>)
List pgsql-hackers
On Thu, Jul 8, 2021 at 10:40 PM Hannu Krosing <hannuk@google.com> wrote:
>
> Very nice results.
>
> I have been working on the same problem but a bit different solution -
> a mix of binary search for (sub)pages and 32-bit bitmaps for
> tid-in-page.
>
> Even with currebnt allocation heuristics (allocate 291 tids per page)
> it initially allocate much less space, instead of current 291*6=1746
> bytes per page it needs to allocate 80 bytes.
>
> Also it can be laid out so that it is friendly to parallel SIMD
> searches doing up to 8 tid lookups in parallel.

Interesting.

>
> That said, for allocating the tid array, the best solution is to
> postpone it as much as possible and to do the initial collection into
> a file, which
>
> 1) postpones the memory allocation to the beginning of index cleanups
>
> 2) lets you select the correct size and structure as you know more
> about the distribution at that time
>
> 3) do the first heap pass in one go and then advance frozenxmin
> *before* index cleanup

I think we have to do index vacuuming before heap vacuuming (2nd heap
pass). So do you mean that it advances relfrozenxid of pg_class before
both index vacuuming and heap vacuuming?

Regards,

--
Masahiko Sawada
EDB:  https://www.enterprisedb.com/



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum
Next
From: "tanghy.fnst@fujitsu.com"
Date:
Subject: RE: [HACKERS] logical decoding of two-phase transactions