Re: [WIP] [B-Tree] Retail IndexTuple deletion - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: [WIP] [B-Tree] Retail IndexTuple deletion
Date
Msg-id CAH2-Wz=dOU0_jXQM4G4M=Kzqom_DgmPfatUHFzpQq3DX6DpDKQ@mail.gmail.com
Whole thread Raw
In response to Re: [WIP] [B-Tree] Retail IndexTuple deletion  (Andrey Lepikhov <a.lepikhov@postgrespro.ru>)
Responses Re: [WIP] [B-Tree] Retail IndexTuple deletion
List pgsql-hackers
On Tue, Aug 7, 2018 at 12:19 AM, Andrey Lepikhov
<a.lepikhov@postgrespro.ru> wrote:
> I wrote a background worker (hcleaner) to demonstrate application of Retail
> IndexTuple deletion (see patch at attachment).
> Like Autovacuum it utilizes concept of one launcher and many workers. But
> one worker correspond to one database.
>
> Short description:
> Backend collects dirty block numbers by a hash table at the point in code
> immediately after heap_page_prune() call. Backend send a package of dirty
> block numbers (not one-by-one!) by socket at the end of transaction or if
> hash table is full.
> Launcher transfers block numbers to correspond workers.
> Worker collects dead tuples from a block, clean index relations, clean heap
> block. It uses conditional locking with waiting list approach if heap block
> are busy.
>
> hcleaner has experimental status, but make check-world passed

How does this affect ordinary opportunistic pruning?

-- 
Peter Geoghegan


pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: Scariest patch tournament, PostgreSQL 11 edition
Next
From: Asim R P
Date:
Subject: Re: Shared buffer access rule violations?