Re: RFE: Make statistics robust for unplanned events
От | Peter Geoghegan |
---|---|
Тема | Re: RFE: Make statistics robust for unplanned events |
Дата | |
Msg-id | CAH2-Wzker1PfvuBWx1A3gRV2rg+G99KnmY1T2CAAaVUMA1YEhg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFE: Make statistics robust for unplanned events (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, Apr 22, 2021 at 3:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Geoghegan <pg@bowt.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
В списке pgsql-hackers по дате отправления: