On Tue, Jun 11, 2019 at 11:47 AM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > On 2019-Apr-10, Alexander Korotkov wrote: > > Alternative idea is to have MVCC-aware indexes. This approach looks > > more attractive for me. In this approach you basically need xmin, > > xmax fields in index tuples. > > "We liked freezing xmin so much that we had to introduce freezing for > xmax" -- rhaas dixit. And now we want to introduce freezing for > indexes?
Plus it would add 8 bytes to the size of every index tuple. if you are indexing long-ish strings it may not hurt too much, but if your primary key is an integer, I think your index is going to get a lot bigger. The problem with freezing is perhaps avoidable if you store an epoch in the page special space as part of all this. But I don't see any way to avoid having the tuples get wider. Possibly you could include xmin and xmax only when needed, removing xmin once the tuples are all-visible and splitting pages if you need to make room to add an xmax. I'm not sure how much that helps, though, because if you do a bulk insert, you're going to have to leave room for all of the xmins initially, and removing them later will produce free space for which you may have little use. I don't think that including visibility information in indexes is a bad idea; we've thought about making zheap do this someday. But I think that we need to use some more sophisticated approach involving, maybe, undo pointers, or some other kind of magic, rather than just widening the tuples. I expect that just widening the tuples would be good enough to win for some use cases, but I think there would be others that lose heavily. In any case, I agree that we do not want to create more things that need freezing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
