| From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Deleting older versions in unique indexes to avoid page splits |
| Date: | 2020-10-22 17:11:58 |
| Message-ID: | CANP8+j+7FCoOh1ryJPowhHi0hc6R-xH+m8jRfDHNAGC6brUu7g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 16 Oct 2020 at 20:12, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> The TPS/throughput is about what you'd expect for the two hour run:
>
> 18,988.762398 TPS for the patch
> 11,123.551707 TPS for the master branch.
Very good.
> Patch:
>
> statement latencies in milliseconds:
> 0.294 UPDATE pgbench_accounts SET abalance = abalance +
> :delta WHERE aid = :aid1;
>
> Master:
>
> statement latencies in milliseconds:
> 0.604 UPDATE pgbench_accounts SET abalance = abalance +
> :delta WHERE aid = :aid1;
The average latency is x2. What is the distribution of latencies?
Occasional very long or all uniformly x2?
I would guess that holding the page locks will also slow down SELECT
workload, so I think you should also report that workload as well.
Hopefully that will be better in the latest version.
I wonder whether we can put this work into a background process rather
than pay the cost in the foreground? Perhaps that might not need us to
hold page locks??
--
Simon Riggs http://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-10-22 17:34:24 | Re: ECPG gets embedded quotes wrong |
| Previous Message | Pavel Stehule | 2020-10-22 16:31:07 | Re: Change JOIN tutorial to focus more on explicit joins |