Hi, On 2019-06-11 11:59:36 -0400, Robert Haas wrote: > 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.
Yea, I think there's plenty reasons to want to do something different than what we're doing. But I'd like to see a concrete proposal before building API for it... Greetings, Andres Freund
