> On Fri, Sep 21, 2018 at 5:52 AM Andrey Lepikhov <a.lepik...@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