Hi hackers, > I'm wondering whether the safest way to handle this is by creating a > new TAM called "heap64", so that all storage changes happens there.
> Many current users see stability as one of the greatest strengths of > Postgres, so while I very much support this move, I wonder if this > gives us a way to have both stability and innovation at the same time? That would be nice. However from what I see TransactionId is a type used globally in PostgresSQL. It is part of structures used by TAM interface, used in WAL records, etc. So we will have to learn these components to work with 64-bit XIDs anyway and then start thinking about cases like: when a user runs a transaction affecting two tables, a heap32 one and heap64 one and we will have to figure out which tuples are visible and which are not. This perhaps is doable but the maintenance burden for the project will be too high IMO. It seems to me that the best option we can offer for the users looking for stability is to use the latest PostgreSQL version with 32-bit XIDs. Assuming these users care that much about this particular design choice of course. > The whole project seems to just ignore basic, pertinent questions. > Questions like: why are we falling behind like this in the first > place? And: If we don't catch up soon, why should we be able to catch > up later on? Falling behind on freezing is still a huge problem with > 64-bit XIDs. Is the example I provided above wrong? """ Consider the case when you run a slow OLAP query that takes 12h to complete and 100K TPS of fast OLTP-type queries on the same system. The fast queries will consume all 32-bit XIDs in less than 12 hours, while the OLAP query started 12 hours ago didn't finish yet and thus its tuples can't be frozen. """ If it is, please let me know. I would very much like to know if my understanding here is flawed. -- Best regards, Aleksander Alekseev
