Hi, Greg! Thank you for your work. It looks huge.
On Tue, Jun 30, 2026 at 8:21 PM Greg Burd <[email protected]> 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 the > new tuple heap-only with its inline bitmap, and the executor inserts fresh > entries only into the indexes whose attributes changed > (ExecSetIndexUnchanged); > 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 => T1, logical contents of I2 is V21 => T1, V22 => 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
