Re: pg_xlogdump --stats
От | Heikki Linnakangas |
---|---|
Тема | Re: pg_xlogdump --stats |
Дата | |
Msg-id | 54116C2A.2080007@vmware.com обсуждение исходный текст |
Ответ на | Re: pg_xlogdump --stats (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: pg_xlogdump --stats
(Abhijit Menon-Sen <ams@2ndQuadrant.com>)
|
Список | pgsql-hackers |
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@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. > > 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
В списке pgsql-hackers по дате отправления: