Horton
Menu

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

Andy Fan <zhihuifan1213@163.com>

View thread
From: Andy Fan <zhihuifan1213@163.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-11-08T00:38:49Z
Lists: pgsql-hackers 
Andy Fan <zhihuifan1213@163.com> writes:

> (3). DELETE does generate new index entry, but we might not touch
> the indexes at all during deletes (*except the index we used for index
> scan*).

I still not check the code right now (it may still take times for me
even I understand the overall design). So do we need to mark the
"garbage" hints for DELETE with a index scan?  The case in my mind is:

CREATE TABLE t(a INT, B int);
CREATE INDEX t_a_idx on t(a);
CREATE INDEX t_b_idx on t(b);

DELETE FROM t WHERE b = 1;

If the delete goes with Index Scan of t_b_idx, we still have the chances
to mark hints on t_b_idx, so that it can be useful during index split?

-- 
Best Regards
Andy Fan

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.