Re: [WIP] [B-Tree] Retail IndexTuple deletion

09.08.2018 05:19, Peter Geoghegan пишет:
> On Tue, Aug 7, 2018 at 12:19 AM, Andrey Lepikhov
> <a(dot)lepikhov(at)postgrespro(dot)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?
>
As far as I understand, background worker not affect on ordinary
opportunistic pruning. For a dirty block it made cleaning work like
vacuum (if acquire conditional lock).

I tried two ways:
1. In executor: tid of deleted/updated tuples collects directly in
executor and send to background worker. Background worker make
heap_page_prune() himself.
But this is no good variant, because each backend perform opportunistic
pruning and it is sufficient work to detect dead tuples. Moreover, in
this case the worker compete with backends for pruning and has high load
when many backends existed.
2. In heap_page_prune_opt(): backend collects ids of dirty blocks
immediately after pruning and send it to the worker. In this case
backend perform all work for detection of dead tuples. It let the worker
to miss block cleaning during periods of heavy load: later it can clean
block.
Since locks are conditional we do not hamper backends work during high
load periods and utilize idle time for relation cleaning in soft manner.

Variant No.2 look better better and now i use it.

--
Andrey Lepikhov
Postgres Professional
https://postgrespro.com
The Russian Postgres Company