From: | Patrik Novotny <panovotn(at)redhat(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RFE: Make statistics robust for unplanned events |
Date: | 2021-04-23 08:51:02 |
Message-ID: | CAE_EZkhU5B+FmTS6fSQtxoxgvQ=nbLA+PGrXdEdw-f78hdW_6A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
>
> Yeah, that's what I was thinking as well -- dumping snapshot at
> regular intervals, so that on crash recovery we lose a "controlled
> amount" of recent starts instead of losing *everything*.
>
> I think in most situations a fairly long interval is OK -- if you have
> tables that take so many hits that you need a really quick reaction
> from autovacuum it will probably pick that up quickly enough even
> after a reset. And if it's moer the long-term tracking that's
> important, then a longer interval is probably OK.
>
> But perhaps make it configurable with a timeout and a "reasonable default"?
>
>
> > Patrik, for your use cases, would loosing at most the stats since the
> > start of last checkpoint be an issue?
>
> Unless there's a particular benefit to tie it specifically to the
> checkpoint occuring, I'd rather keep it as a separate setting. They
> might both come with the same default of course, btu I can certainly
> envision cases where you want to increase the checkpoint distance
> while keeping the stats interval lower for example. Many people
> increase the checkpoint timeout quite a lot...
>
>
From what I understand, I think it depends on the interval of those
checkpoints. If the interval was configurable with the mentioned reasonable
default, then it shouldn't be an issue.
If we were to choose a hard coded interval of those checkpoints based on my
case, I would have to consult the original reporter, but then it might not
suit others anyway. Therefore, making it configurable makes more sense to
me personally.
--
Patrik Novotný
Associate Software Engineer
Red Hat
panovotn(at)redhat(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | osumi.takamichi@fujitsu.com | 2021-04-23 09:03:02 | RE: Truncate in synchronous logical replication failed |
Previous Message | Laurenz Albe | 2021-04-23 08:33:39 | Re: Support tab completion for upper character inputs in psql |