Re: pg_xlogdump --stats

On 09/11/2014 12:22 PM, Andres Freund wrote:
> On 2014-09-11 12:14:42 +0300, Heikki Linnakangas wrote:
>> On 09/11/2014 11:43 AM, Abhijit Menon-Sen wrote:
>>> At 2014-08-21 10:06:39 +0300, hlinnakangas(at)vmware(dot)com wrote:
>>>> I think the names that rm_identify returns should match those that the
>>>> rm_desc functions print.
>>>
>>> I had originally started off trying to keep the output in sync, but it
>>> doesn't work very well. There are rm_desc functions that print things
>>> like "truncate before" and "Create posting tree", and many decisions
>>> are quite arbitrary ("freeze_page", "cleanup info", "multi-insert").
>>
>> It would be good to clean up those messages to be more sensible and
>> consistent.
>
>>> I think it's better the (grep-friendly) way it is. If anything, perhaps
>>> rm_desc should output "${rm_identify}[: optional explanation]". That
>>> would also make it very clear what should go in rm_identify and what
>>> should go in rm_desc.
>
>> Yeah, that makes sense too.
>
> I'm not sure I agree here. From a theoretical POV sure, but wouldn't
> that lead to even longer lines for xlogdump and other error messages for
> some records?

No. All the rm_desc functions already follow that convention, and print
"foo: details", where "foo" identifies the record type based on xl_info.
This proposal would just make that convention more official, and
stipulate that the "foo" part should match what the new rm_identify()
function returns. (Or perhaps even better, define it so that rm_desc
prints only the "details" part, and rm_identify() the "foo" part, and
have the callers put the two strings together if they want)

>> There are similar cases in B-tree splits, for
>> example, where a split where the new tuple goes to the left half is
>> considered a different record type than one where it goes ot the right half.
>> It might be interesting to count them separately in the stats, but then
>> again it might just be confusing. The xl_info flags and the rm_desc output
>> were never intended to be a useful categorization for statistics purposes,
>> so it's not surprising that it's not too well suited for that. Nevertheless,
>> the "pg_xlogdump --stats" is useful as it is, if you know the limitations.
>
> I agree it's not perfect, but I think it's a huge step forward. We very
> well might want to improve upon the stats granularity once in, but I
> think it already gives a fair amount of direction where to look.

Agreed. That's what I was also trying to say.

- Heikki