On 09/11/2014 11:43 AM, Abhijit Menon-Sen wrote:
At 2014-08-21 10:06:39 +0300, hlinnakan...@vmware.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.
The corresponding rm_identify output is:
HOT_UPDATE+INIT
The +INIT is admittedly a special case, and I would have no objection to
writing that as (INIT) or something instead.
I don't care much, as long as it's consistent the rm_desc output.
It's quite arbitrary that the INIT cases are considered different record
types, with their own "identity" string, instead of being just a flag in
the same record type. It's an implementation detail that that flag is
stored in the xl_info, and that implementation detail is now exposed in
the stats pg_xlogdump --stats output. 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.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
