Re: [DOCS] Patch for monitoring.sgml
BTW, context diffs (diff -c) are preferred. For SGML patches, unified diffs (diff -u) are okay as well. On Sun, 2007-04-22 at 16:10 +0200, Guillaume Lelarge wrote: > This patch adds a sentence on monitoring.sgml explaining that > stats_row_level needs to be enabled if user wants to get last > vacuum/analyze execution time. Why is this so? It sounds more like a bug than a feature to me. -Neil ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [DOCS] Patch for monitoring.sgml
Neil Conway a écrit : BTW, context diffs (diff -c) are preferred. For SGML patches, unified diffs (diff -u) are okay as well. On Sun, 2007-04-22 at 16:10 +0200, Guillaume Lelarge wrote: This patch adds a sentence on monitoring.sgml explaining that stats_row_level needs to be enabled if user wants to get last vacuum/analyze execution time. Why is this so? It sounds more like a bug than a feature to me. I don't know why it works this way. Perhaps it wasn't the developer's intention but, anyway, actually, it works like that. -- Guillaume. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[DOCS] row-level stats and last analyze time
[ CC'ing -hackers ] On Sun, 2007-04-22 at 16:10 +0200, Guillaume Lelarge wrote: > This patch adds a sentence on monitoring.sgml explaining that > stats_row_level needs to be enabled if user wants to get last > vacuum/analyze execution time. This behavior was introduced in r1.120 of postmaster/pgstat.c: Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze [...] which included other modifications to reduce the pgstat I/O volume in 8.1. I don't think this particular change was wise: the reduction in pgstat volume is pretty marginal, and it is counter-intuitive for stats_row_level to effect whether the last ANALYZE / VACUUM is recorded. (Plus, the optimization is not even enabled with the default postgresql.conf settings.) -Neil ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [DOCS] row-level stats and last analyze time
On Tuesday 24 April 2007 17:38, Neil Conway wrote:
> [ CC'ing -hackers ]
>
> On Sun, 2007-04-22 at 16:10 +0200, Guillaume Lelarge wrote:
> > This patch adds a sentence on monitoring.sgml explaining that
> > stats_row_level needs to be enabled if user wants to get last
> > vacuum/analyze execution time.
>
> This behavior was introduced in r1.120 of postmaster/pgstat.c:
>
> Modify pgstats code to reduce performance penalties from
> oversized stats data files: avoid creating stats
> hashtable entries for tables that aren't being touched
> except by vacuum/analyze [...]
>
> which included other modifications to reduce the pgstat I/O volume in
> 8.1. I don't think this particular change was wise: the reduction in
> pgstat volume is pretty marginal, and it is counter-intuitive for
> stats_row_level to effect whether the last ANALYZE / VACUUM is recorded.
> (Plus, the optimization is not even enabled with the default
> postgresql.conf settings.)
>
+1
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
