> > > 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 panov...@redhat.com
