On Mon, Jun 24, 2019 at 1:43 PM Alvaro Herrera <alvherre@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_U2jFQ@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.