MIME-Version: 1.0
References: <af02b486-6adc-494c-a357-1dd72f655dcf@app.fastmail.com>
In-Reply-To: <af02b486-6adc-494c-a357-1dd72f655dcf@app.fastmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Thu, 9 Jul 2026 14:26:44 +0300
Message-ID: 
 <CAPpHfdvOLrULXQn+s+bEG4QiVrps+_3mg2EjUN39OYUKoBE20w@mail.gmail.com>
Subject: Re: Tepid: selective index updates for heap relations
To: Greg Burd <greg@burd.me>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAPpHfdvOLrULXQn%2Bs%2BbEG4QiVrps%2B_3mg2EjUN39OYUKoBE20w%40mail.gmail.com>
Precedence: bulk

Hi, Greg!

Thank you for your work.  It looks huge.

On Tue, Jun 30, 2026 at 8:21=E2=80=AFPM Greg Burd <greg@burd.me> wrote:
> Write path.  heap_update gains a third mode (HEAP_SELECTIVE_INDEX_UPDATE)
> alongside HEAP_UPDATE_ALL_INDEXES and HEAP_HEAP_ONLY_UPDATE.  It keeps th=
e
> new tuple heap-only with its inline bitmap, and the executor inserts fres=
h
> entries only into the indexes whose attributes changed (ExecSetIndexUncha=
nged);
> the fresh entry points at the new heap-only tuple, not at the chain root.
> If the page can't fit the new tuple, the update is downgraded to a normal
> non-HOT update.

I didn't yet read the whole design nor the whole patches.  But this is
the point that raises questions for me.  How could this work with the
present Bitmap Scans?  I didn't find the direct answer in this thread.
As you describe, entries to the indexes whose attributes changed are
pointing to the new heap-only tuple (that effectively makes the tuple
not heap-only, but that's just terminology question).  For instance,
you have old tuple T1, "new heap-only tuple" T2, unchanged index I1,
and changed index I2.  Both T1 and T2 have values V11 for I1.  T1 and
T2 have  values V21 and V22 for I2 correspondingly.  So, in this
example according the paragraph above the logical contents of I1 is:
V11 =3D> T1, logical contents of I2 is V21 =3D> T1, V22 =3D> T2.  Imagine,
user searches for the tuple containing V11 for I1 and V22 for I2 with
BitmapAnd.  I1 side of BitmapAnd will return ctid of T1, while I2 side
of BitmapAnd will return ctid of T2.  That gives nothing in the
intersection, while T2 is obviously matches the criteria.

As you mention downthread, Bitmap Scan can tolerate false positives,
but it can't tolerate false negatives.  Bitmap Scan assumes CTIDs to
be independently indexed pointers, and therefore corresponding bitmaps
could be freely overlapped.  I think Bitmap Scans was one of the
critical weakness in WARM, and it is the question to be address in any
further attempt in this direction.

------
Regards,
Alexander Korotkov
Supabase