Re: RFE: Make statistics robust for unplanned events - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: RFE: Make statistics robust for unplanned events
Date
Msg-id CABUevExUGTrDA0c7BfvQvjmVtk95Uk9=qYGymYVoJ_G04TgZ8Q@mail.gmail.com
Whole thread Raw
In response to RFE: Make statistics robust for unplanned events  (Patrik Novotny <panovotn@redhat.com>)
Responses Re: RFE: Make statistics robust for unplanned events  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Re: RFE: Make statistics robust for unplanned events  (Peter Geoghegan <pg@bowt.ie>)
Re: RFE: Make statistics robust for unplanned events  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Tue, Apr 20, 2021 at 2:00 PM Patrik Novotny <panovotn@redhat.com> wrote:
>
> Hello PostgreSQL Hackers,
>
> is it possible to preserve the PostgreSQL statistics on a server crash?
>
> Steps to reproduce the behaviour:
> 1) Observe the statistics counters, take note
> 2) Crash the machine, e.g. with sysrq; perhaps kill -9 on postgresql will already suffice
> 3) After recovery, observe the statistics counter again. Have they been reset to zero (Bad) or are they preserved
(Good).
>
> Resetting the counters to zero harms execution planning and auto_vacuum
> operations. That can cause growth of database as dead tuples are not removed
> at the right time. In the end the database can go offline if autovacuum never runs.

The stats for the planner are store persistently in pg_stats though,
but autovacuum definitely takes a hit from it, and several other
things can too.

> As far as I've checked, this would have to be implemented.
>
> My question would be whether there is something that would make this impossible to implement, and if there isn't, I'd
likethis to be considered a feature request.
 

I'm pretty sure everybody would *want* this. At least nobody would be
against it. The problem is the potential performance cost of it.

Andres mentioned at least once over in the thread about shared memory
stats collection that being able to have persistent stats could come
out of that one in the future. Whatever is done on the topic should
probably be done based on that work, as it provides a better starting
point and also one that will stay around.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: prerequisites of pull_up_sublinks
Next
From: Amit Langote
Date:
Subject: Re: Table refer leak in logical replication