From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: decoupling table and index vacuum |
Date: | 2021-04-24 18:59:29 |
Message-ID: | CAH2-WzkVqOjszv5UvX_t5fRtXggWWhVafOEFV9vS8thqMEVf0Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Apr 24, 2021 at 11:43 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I don't see how that's good enough as a general approach. It won't work
> on indexes that insert on one end, delete from the other (think
> inserted_at or serial primary keys in many workloads).
That can be treated as another extreme that we need to treat as
negative feedback. There may also be other types of negative feedback
that occur only in some index AMs, that neither of us have thought of
just yet. But that's okay -- we can just add that to the list. Some
varieties of negative feedback might be much more common in practice
than others. This shouldn't matter.
The number of live tuples (or even dead tuples) in the whole entire
index is simply not a useful proxy for what actually matters -- this
is 100% clear. There are many cases where this will do completely the
wrong thing, even if we have perfectly accurate information. I'll
spare you a repeat of the example of bottom-up index deletion and
"Schrodinger's dead index tuples" (it's not the only example, just the
purest).
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2021-04-24 19:09:45 | cleaning up PostgresNode.pm |
Previous Message | Andres Freund | 2021-04-24 18:43:12 | Re: decoupling table and index vacuum |