Hannu Krosing <[EMAIL PROTECTED]> writes:
> Ãhel kenal päeval, T, 2007-02-13 kell 09:38, kirjutas Tom Lane:
>> It's all moot anyway since 8 bits isn't enough for a pointer ...
> With 8k pages and MAXALIGN=8 we just barely can, as with current page
> structure (tuple headers together with data) the minimal tuple size for
> that case is 24 for header + 8 for data = 32 bytes which means 256
> tuples per page (minus page header) and so we can store tuple number in
> 8 bits.
But neither of those assumptions is acceptable --- I would think in fact
that people would become *more* interested in having large pages with
HOT, because it would give more room for updates-on-the-same-page.
Besides, you forgot the case of an empty tuple (<= 8 columns, all NULL).
> OTOH, for same page HOT tuples, we have the command and trx ids stored
> twice first as cmax,xmax of the old tuple and as cmin,xmin of the
> updated tuple. One of these could probably be used for in-page HOT tuple
> pointer.
This proposal seems awfully fragile, because the existing
tuple-chain-following logic *depends for correctness* on comparing each
tuple's xmin to prior xmax. I don't think you can just wave your hands
and say we don't need that cross-check. Furthermore it seems to me you
haven't fixed the problem, which is that you can't remove the chain
member that is being pointed at by off-page links (either index entries
or a previous generation of the same tuple). As described, you've made
that problem worse because you're trying to say we don't know which of
the chain entries is pointed at.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
