On Sat, 2022-04-02 at 18:56 +0800, Julien Rouhaud wrote: > Maybe a macro would be better here? I don't know if that's generally > ok or > just old and not-that-great code, but there are other places relying > on macros > when a plain function call isn't that convenient (like here returning > 0 or 1 as > a hack for incrementing num_remove), for instance in hba.c.
Yes, it is not very convenient and not looks pretty, so I'll try a macro here soon. > > I think that if we can do it in accurate way and there is no > > obvious > > side effects, why not to try it... > > Changing of pg_stat_statements_reset function result caused a > > confiderable tests update. Also, I'm not sure that my description > > of > > this feature in the docs is blameless.. > > > > After all, I'm a little bit in doubt about this feature, so I'm > > ready > > to rollback it. > > Well, I personally don't think that I would need it for powa as it's > designed > to have very frequent snapshot. I know you have a different approach > in > pg_profile, but I'm not sure it will be that useful for you either? Of course I can do some workaround if the accurate reset time will be unavailable. I just want to do the whole thing if it doesn't hurt. If we have a plenty of timestamps saved now, I think it is a good idea to have then bound to some milestones. At least it is a pretty equal join condition between samples. But if you think we should avoid returning ts here I won't insist on that.
