> I'm quite worried about the stability of those counters for regression tests. > Wouldn't a checkpoint happening during the test change them?
Agree, stability of test could be an issue, even shifting of write format or compression method or adding compatible changes could break such test. Frankly speaking, the numbers expected are not actually calculated, my logic was rather well described by "these numbers should be non-zero for real tables". I believe the test can be modified to check that numbers are above zero, both for bytes written and for records stored. Having a checkpoint in the moddle of the test can be almost 100% countered by triggering one before the test. I'll add a checkpoint call to the test scenario, if no objections here. > While at it, did you consider adding a full-page image counter in the > WalUsage? > That's something I'd really like to have and it doesn't seem hard to > integrate. Well, not sure I understand you 100%, being new to Postgres dev. Do you want a separate counter for pages written whenever doPageWrites is true? I can do that, if needed. Please confirm. > Another point is that this patch won't help to see autovacuum activity. > As an example, I did a quick te..... > ...LONG QUOTE... > but that may seem strange to only account for (auto)vacuum activity, rather > than globally, grouping per RmgrId or CommandTag for instance. We could then > see the complete WAL usage per-database. What do you think? I wanted to keep the patch small and simple, and fit to practical needs. This patch is supposed to provide tuning assistance, catching an io heavy query in commit-bound situation. Total WAL usage per DB can be assessed rather easily using other means. Let's get this change into the codebase and then work on connecting WAL usage to (auto)vacuum stats. > > Some minor points I noticed: > > - the extension patch doesn't apply anymore, I guess since 70a7732007bc4689 Will fix, thank you. > > #define PARALLEL_KEY_JIT_INSTRUMENTATION UINT64CONST(0xE000000000000009) > +#define PARALLEL_KEY_WAL_USAGE UINT64CONST(0xE000000000000010) > > Shouldn't it be 0xA rather than 0x10? Oww, my bad, this is embaracing! Will fix, thank you. > - it would be better to add a version number to the patches, so we're sure > which one we're talking about. Noted, thank you. Please comment on the proposed changes, I will cook up a new version once all are agreed upon.