From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Patrik Novotny <panovotn(at)redhat(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RFE: Make statistics robust for unplanned events |
Date: | 2021-05-01 00:23:06 |
Message-ID: | CAH2-Wzker1PfvuBWx1A3gRV2rg+G99KnmY1T2CAAaVUMA1YEhg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 22, 2021 at 3:35 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> > We already *almost* pay the full cost of durably storing the
> > information used by autovacuum.c's relation_needs_vacanalyze() to
> > determine if a VACUUM is required -- we're only missing
> > new_dead_tuples/tabentry->n_dead_tuples. Why not go one tiny baby step
> > further to fix this issue?
>
> Definitely worth thinking about, but I'm a little confused about how
> you see this working. Those pg_class fields are updated by vacuum
> (or analyze) itself. How could they usefully serve as input to
> autovacuum's decisions?
Honestly, the details weren't very well thought out. My basic point
still stands, which is that it shouldn't be *that* expensive to make
the relevant information crash-safe, which would protect the system
from certain pathological cases. Maybe it doesn't even have to be
crash-safe in the way that pg_class.reltuples is -- something
approximate might work quite well. Assuming that there are no dead
tuples after a crash seems rather naive.
I seem to recall that certain init scripts I saw years ago used
Immediate Shutdown mode very frequently. Stuff like that is bound to
happen in some installations, and so we should protect users from
hard-to-foresee extreme consequences. Sure, using immediate shutdown
like that isn't recommended practice, but that's no reason to allow a
nasty failure mode.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2021-05-01 02:00:35 | Re: Granting control of SUSET gucs to non-superusers |
Previous Message | Masahiko Sawada | 2021-05-01 00:22:59 | Re: Transactions involving multiple postgres foreign servers, take 2 |