Re: [PATCH v1 1/1] Add GENERATED ALWAYS AS ROW IDENTITY columns

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