From: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
---|---|
To: | a(dot)lepikhov(at)postgrespro(dot)ru |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [WIP] [B-Tree] Retail IndexTuple deletion |
Date: | 2018-11-29 13:27:50 |
Message-ID: | CA+q6zcV9rkCdZbt4DDyUXCZupB_2vLH0NKtCF6iR=dganGP_vg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Fri, Sep 21, 2018 at 5:52 AM Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2018-11-29 13:28:36 | Re: [PATCH] Change "checkpoint starting" message to use "wal" |
Previous Message | Alvaro Herrera | 2018-11-29 13:27:07 | Re: New GUC to sample log queries |