From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Indirect indexes |
Date: | 2016-10-19 22:45:48 |
Message-ID: | 20161019224548.lr3oy4pkaadeafvw@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alexander Korotkov wrote:
Hi,
> Thank you for your proposal. One question about vacuum excites me most.
> Imagine another situation: PK column was not updated, but indirect indexed
> column was updated.
> Thus, for single heap tuple we would have single PK tuple and two indirect
> index tuples (correct me if I'm wrong).
> How are we going to delete old indirect index tuple?
Yeah, this is a tough question all right.
Another thing to note is that the initial heap tuple might be removed
via HOT page pruning, so it will not be there during vacuuming either;
there would only be a redirect line pointer. So I don't think we can
rely on that to figure out an exact cleanup of the indirect index.
One possibility is to forget about vacuuming the index altogether.
Instead we can rely solely on the killtuple interface, that is, have
obsolete tuples be removed during index scanning.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter van Hardenberg | 2016-10-19 23:26:57 | Re: Patch: Implement failover on libpq connect level. |
Previous Message | Alvaro Herrera | 2016-10-19 22:30:47 | Re: Avoiding pin scan during btree vacuum |