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

From Andres Freund
Subject Re: [WIP] [B-Tree] Retail IndexTuple deletion
Date
Msg-id 20190131112045.24mech7xg4anyibz@alap3.anarazel.de
Whole thread Raw
In response to Re: [WIP] [B-Tree] Retail IndexTuple deletion  (Dmitry Dolgov <9erthalion6@gmail.com>)
List pgsql-hackers
On 2018-11-29 14:27:50 +0100, Dmitry Dolgov wrote:
> > On Fri, Sep 21, 2018 at 5:52 AM Andrey Lepikhov <a.lepikhov@postgrespro.ru> wrote:
> >
> > The v6 version of quick vacuum, which utilizes the amtargetdelete()
> > interface for retail indextuple deletion.
> > Now it is more simple and laconic.
> > It must be applied after Retail-IndexTuple-Deletion-Access-Method.patch.
> >
> > BENCHMARKS:
> > -----------
> >
> > Initial script:
> > pgbench -i -s $scale # initial DB generation
> > "CREATE INDEX pgbench_accounts_ext ON public.pgbench_accounts USING
> > btree (abalance);" # additional index
> >
> > Comparison with lazy vacuum:
> >
> > script:
> > "DELETE FROM pgbench_accounts WHERE (random() < $factor);" # delete a
> > part of tuples for cleaning strategies comparison
> > "VACUUM pgbench_accounts;" # check time of vacuum process by bash 'date
> > +%s%N | cut -b1-13' command
> >
> > Results:
> >         | $scale=10   | $scale=100  |
> > $factor| QVAC | LVAC | QVAC | LVAC |
> > 1E-6   | -    | -    | 284  | 979  |
> > 1E-5   | 78   | 144  | 288  | 1423 |
> > 1E-4   | 72   | 280  | 388  | 3304 |
> > 1E-3   | 189  | 609  | 2294 | 6029 |
> > 1E-2   | 443  | 783  | 54232| 67884|
> > 1E-1   | 1593 | 1237 | 83092| 86104|
> >
> > where QVAC - forced use of quick vacuum; LVAC - use lazy vacuum for
> > index cleanup. $factor corresponds a number of vacuumed tuples. For
> > example, $scale=10, $factor=1E-1 -> 100000 tuples vacuumed. Time
> > measured in ms.
> >
> > So, quick strategy can be used in a vacuum process effectively up to
> > 1-2% of DEAD tuples in a relation.
> 
> Hi,
> 
> Unfortunately, this patch doesn't compile anymore:
> 
> index.c: In function ‘htid2IndexDatum’:
> index.c:4172:2: error: too few arguments to function ‘MakeSingleTupleTableSlot’
>   TupleTableSlot *slot = MakeSingleTupleTableSlot(RelationGetDescr(hrel));
>   ^
> 
> Also I'm a bit confused about the current status of collaboration between this
> patch and [1], one is tightly depends on another or not? Does it makes sense
> to have only one corresponding CF item then? For now I'll move this one to
> the next CF.
> 
> [1]:
https://www.postgresql.org/message-id/flat/CAH2-WzkVb0Kom%3DR%2B88fDFb%3DJSxZMFvbHVC6Mn9LJ2n%3DX%3DkS-Uw%40mail.gmail.com


Given this patch has not been updated since Dmitry's message above, I'm
marking this as returned with feedback.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] WIP: long transactions on hot standby feedback replica/ proof of concept
Next
From: Andres Freund
Date:
Subject: Re: Implementing SQL ASSERTION