On Thu, Jun 22, 2017 at 4:27 PM, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > Can you elaborate a bit more about this TID bit pattern issues? I do > remember that not all TIDs are valid due to safeguards on individual fields, > like for example > > Assert(iptr->ip_posid < (1 << MaxHeapTuplesPerPageBits)) > > But perhaps there are some other issues?
I think the other issues that I know about have largely already been mentioned by others, but since this question was addressed to me: 1. TID bitmaps assume that the page and offset parts of the TID contain just those things. As Tom pointed out, tidbitmap.c isn't cool with TIDs that have ip_posid out of range. More broadly, we assume lossification is a sensible way of keeping a TID bitmap down to a reasonable size without losing too much efficiency, and that sorting tuple references by the block ID is likely to produce a sequential I/O pattern. Those things won't necessarily be true if TIDs are treated as opaque tuple identifiers. 2. Apparently, GIN uses the structure of TIDs to compress posting lists. (I'm not personally familiar with this code.) In general, it's a fairly dangerous thing to suppose that you can repurpose a value as widely used as a TID and not break anything. I'm not saying it can't be done, but we use TIDs in an awful lot of places and rooting out all of the places somebody may have made an assumption about the structure of them may not be trivial. I tend to think it's an ugly kludge to shove some other kind of value into a TID, anyway. If we need to store something that's not a TID, I think we should have a purpose-built mechanism for that, not just hammer on the existing system until it sorta works. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
