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

From Patrik Novotny
Subject Re: RFE: Make statistics robust for unplanned events
Date
Msg-id CAE_EZkhU5B+FmTS6fSQtxoxgvQ=nbLA+PGrXdEdw-f78hdW_6A@mail.gmail.com
Whole thread Raw
In response to Re: RFE: Make statistics robust for unplanned events  (Magnus Hagander <magnus@hagander.net>)
List 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@redhat.com  

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: RFE: Make statistics robust for unplanned events
Next
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: RE: Truncate in synchronous logical replication failed