Re: RFE: Make statistics robust for unplanned events

From: Patrik Novotny <panovotn(at)redhat(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFE: Make statistics robust for unplanned events
Date: 2021-04-22 08:57:37
Message-ID: CAE_EZkg4=Mom_nJMjkonG48gaKVvBG2ZDHDx1YnjdQm9700dgg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 21, 2021 at 5:05 PM Magnus Hagander <magnus(at)hagander(dot)net> wrote:

>
> > Right. I think the other question is how often does this happen in
> > practice - if your instance crashes often enough to make this an issue,
> > then there are probably bigger issues.
>
> Agreed.
>
> I think the bigger problem there is replication failover, but that's
> also a different issue (keeping the statistics from the *standby*
> wouldn't help you much there, you'd need to replicate it from the
> primary).
>
> --
> Magnus Hagander
> Me: https://www.hagander.net/
> Work: https://www.redpill-linpro.com/
>
>
The report that I've received regarding this RFE has been triggered by
experiencing issues with long term deployments in a large scale industrial
environment. The point of this RFE is to be protected against those issues
in the future. While this doesn't seem to be a very frequent occurrence, I
wouldn't consider this a corner case not being worth attention.

If there is an expectation for the performance loss to be less of a problem
in the future, would it make sense to make this an opt-in feature until
then?

--
Patrik Novotný
Associate Software Engineer
Red Hat
panovotn(at)redhat(dot)com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message houzj.fnst@fujitsu.com 2021-04-22 09:08:49 RE: [bug?] Missed parallel safety checks, and wrong parallel safety
Previous Message Justin Pryzby 2021-04-22 08:56:14 Re: TRUNCATE on foreign table