From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: MaxOffsetNumber for Table AMs |
Date: | 2021-05-03 18:43:08 |
Message-ID: | CAH2-Wzme-1eXK1iBbcVGdJLDep=UonwkrFL62pD2BqxTcU2AVA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 3, 2021 at 10:57 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> For the purposes of this discussion, what's making my life difficult is
> that we don't have a good definition for TID, leaving me with two
> options:
>
> 1. be overly conservative, accept MaxOffsetNumber=2048, wasting a
> bunch of address space; or
tidbitmap.c uses MaxHeapTuplesPerPage as its MAX_TUPLES_PER_PAGE,
which is much lower than MaxOffsetNumber (it's almost 10x lower). I
wonder what that means for your design.
> 2. risk the mapping between TID and row number could break at any
> time
Though this clearly is the immediate problem for you, I think that the
real problem is that the table AM kind of tacitly assumes that there
is a universality to item pointer TIDs -- which is obviously not true.
It might be useful for you to know what assumptions index AMs can make
about how TIDs work in general, but I think that you really need an
index-AM level infrastructure that advertises the capabilities of each
index AM with respect to handling each possible variation (I suppose
you have heapam, 6 byte uint, and maybe 8 byte uint).
The easiest reasonable short term design for you is probably to find a
way to make 6 byte TIDs into 48-bit unsigned integers (perhaps only
conceptually), at least in contexts where the columnar table AM is
used. You'll still need the index AM for that. This at least makes
64-bit TID-like identifiers a relatively simple conceptually shift.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-05-03 18:48:04 | Re: Granting control of SUSET gucs to non-superusers |
Previous Message | Stephen Frost | 2021-05-03 18:41:07 | Re: Granting control of SUSET gucs to non-superusers |