Re: pg_stats_recovery view - Mailing list pgsql-hackers

From Bernd Helmle
Subject Re: pg_stats_recovery view
Date
Msg-id 1CF2DED1B9CCC3579917EB9E@apophis.local
Whole thread Raw
In response to Re: pg_stats_recovery view  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers

--On 2. Februar 2012 17:12:11 +0900 Fujii Masao <masao.fujii@gmail.com> wrote:

> If only core developer is interested in this view, ISTM that short
> description for
> each WAL record is not required because he or she can know the meaning of each
> WAL record by reading the source code. No? Adding short descriptions for every
> WAL records seems to be overkill.

Yes, for a developer option alone adding all these *_short_desc functions looks
too much code for too less benefit. However, if someone with less code affinity
is interested to debug his server during recovery, it might be easier for him 
to interpret the statistic counters.

Unfortunately i didn't manage to do it this week, but what i'm also interested 
in is how large the performance regression is if the track_recovery variable is 
activated. Not sure wether it really makes a big difference, but maybe 
debugging recovery from a large archive could slow down to a degree, where you 
want the GUC but can't afford it?

And, for display purposes, when this is intended for developers only, shouldn't 
it be treated like all the other debug options as a DEVELOPER_OPTION, too?

-- 
Thanks
Bernd


pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Fast GiST index build - further improvements
Next
From: Oleg Bartunov
Date:
Subject: NULL's support in SP-GiST