Re: Indirect indexes

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Indirect indexes
Date: 2016-12-30 22:35:30
Message-ID: 20161230223530.gvu4azrsfqzr5eus@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Attached is v4, which fixes a couple of relatively minor bugs. There
are still things to tackle before this is committable, but coding review
of the new executor node would be welcome.

The big remaining item is still fitting the PK data in TIDs 6 bytes.
I've been looking at reworking the btree code to allow for an arbitrary
size; it doesn't look impossible although it's going to be rather
invasive. Also, vacuuming: my answer continues to be that the killtuple
interface should be good enough, but it's possible to vacuum the index
separately from vacuuming the table anyway if you do a full scan and
check the PK tuples for each indirect tuple.

This patch implements killtuple: a scan that sees an indirect tuple not
returning anything from the heap marks the tuple as LP_DEAD. Later,
when the page is about to be split, those tuples are removed.

I also have a note in the code about not inserting an indirect tuple
when an identical one already exists. This is a correctness issue: we
return duplicated heap rows in certain cases.

Álvaro Herrera
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Attachment Content-Type Size
indirect-indexes-4.patch text/plain 105.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2016-12-31 00:16:24 Re: proposal: session server side variables
Previous Message Vik Fearing 2016-12-30 22:07:56 Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal