Re: Deleting older versions in unique indexes to avoid page splits
От | Simon Riggs |
---|---|
Тема | Re: Deleting older versions in unique indexes to avoid page splits |
Дата | |
Msg-id | CANP8+j+7FCoOh1ryJPowhHi0hc6R-xH+m8jRfDHNAGC6brUu7g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Deleting older versions in unique indexes to avoid page splits (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Deleting older versions in unique indexes to avoid page splits
|
Список | pgsql-hackers |
On Fri, 16 Oct 2020 at 20:12, Peter Geoghegan <pg@bowt.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/
В списке pgsql-hackers по дате отправления: