From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations |
Date: | 2022-01-06 23:58:48 |
Message-ID: | CAH2-WzkfNW0DRBDYF+2jz36aiD7=C17bLY=aCjf160Fha_Z-LA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 6, 2022 at 2:45 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> But the "freeze early" heuristics work a bit like that anyway. We
> won't freeze all the tuples on a whole heap page early if we won't
> otherwise set the heap page to all-visible (not all-frozen) in the VM
> anyway.
I believe that applications tend to update rows according to
predictable patterns. Andy Pavlo made an observation about this at one
point:
https://youtu.be/AD1HW9mLlrg?t=3202
I think that we don't do a good enough job of keeping logically
related tuples (tuples inserted around the same time) together, on the
same original heap page, which motivated a lot of my experiments with
the FSM from last year. Even still, it seems like a good idea for us
to err in the direction of assuming that tuples on the same heap page
are logically related. The tuples should all be frozen together when
possible. And *not* frozen early when the heap page as a whole can't
be frozen (barring cases with one *much* older XID before
FreezeLimit).
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira | 2022-01-07 00:33:07 | fix libpq comment |
Previous Message | Todd Hubers | 2022-01-06 23:55:09 | Re: Feature Proposal: Connection Pool Optimization - Change the Connection User |