On Mon, Jun 24, 2019 at 1:43 PM Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > I think enlarging multixacts to 64 bits is a terrible idea. I would > rather get rid of multixacts completely; zheap is proposing not to use > multixacts at all, for example.
But zedstore, at least as of the Saturday after PGCon, is proposing to keep using them, after first widening them to 64 bits: https://www.postgresql.org/message-id/CA+TgmoYeTeQSmALox0PmSm5Gh03oe=unjhml+k+btofy_u2...@mail.gmail.com I think we all have a visceral reaction against MultiXacts at this point; they've just caused us too much pain, and the SLRU infrastructure is a bunch of crap.[1] However, the case where N sessions all do "SELECT * FROM sometab FOR SHARE" is pretty wretched without multixacts. You'll just have to keep reducing the tuple density per page to fit all the locks, whereas the current heap is totally fine and neither the heap nor the multixact space bloats all that terribly much. I currently think it's likely that zheap will use something multixact-like rather than actually using multixacts per se. I am having trouble seeing how we can have some sort of fixed-bit-width ID number that represents as set of XIDs for purposes of lock-tracking without creating some nasty degenerate cases that don't exist today.[2] -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company [1] At least in comparison to other parts of the PostgreSQL infrastructure which are more awesome. [2] I'd like to credit Andres Freund for helping me understand this issue better.
