On 23/10/2026 13:06, Hannu Krosing wrote:
What it is
========
A row identity type using a 64-bit expanded tuple ID as the identity,
can do direct access, with HOT chains following and backup index
access as backup.
What is an "expanded tuple ID"? Is that like the current 'ctid'? Why
does it need to be 64 bits wide, why is the current 32+16 bits not
sufficient?
What I hope to get out of this is
=======================
- immediate no-downtime ALTER TABLE ... ADD COLUMN .. GENERATED ALWAYS
AS ROW IDENTITY
- much faster point lookups by avoiding index access in most cases
- not needing the index maintenance in most cases, much cheaper in
remaining cases
- should be especially useful in many graph query cases
How does a 64-bit "expanded tuple ID" help to achieve those goals?
What index maintenance?
+/*
+ * 64-bit Row Identity key layout (GENERATED ALWAYS AS ROW IDENTITY):
+ *
+ * Bit 63: 0 (sign bit; keys are always positive 1 .. INT64_MAX)
+ * Bit 62: ROWID_EXTENDED_FLAG (1 if allocated via sequence beyond ctid)
+ * Bits [61:48-S]: partition_id (P bits, where S = Max(0, P - 14))
+ * Bits [47-S:16]: BlockNumber (32 - S bits)
+ * Bits [15:0]: OffsetNumber (16 bits, 1 .. MaxHeapTuplesPerPage)
+ */
Huh, ok so you're storing a partition id in the tid itself. Why? What if
you have more than 2^14 partitions?
I don't understand what you're trying to accomplish here, and this patch
is clearly dead on arrival. Maybe you can explain in simpler terms what
you're trying to accomplish. Everyone is busy, so please try to keep the
scope as narrow as possible.
- Heikki
