Re: Deleting older versions in unique indexes to avoid page splits

Simon Riggs <simon@2ndquadrant.com>

From: Simon Riggs <simon@2ndquadrant.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-10-22T17:11:58Z
Lists: 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/



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Enhance nbtree index tuple deletion.

  2. Pass down "logically unchanged index" hint.

  3. Fix index deletion latestRemovedXid bug.

  4. Deprecate nbtree's BTP_HAS_GARBAGE flag.