From: Tom Lane <tgl@sss.pgh.pa.us>
To: Neil Conway <neilc@samurai.com>
Cc: Guillaume Lelarge <guillaume@lelarge.info>
Cc: pgsql-docs@postgresql.org, pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: row-level stats and last analyze time
Date: Sun, 06 May 2007 21:25:21 -0400
Message-ID: <18709.1178501121@sss.pgh.pa.us> (raw)
In-Reply-To: <1178216419.18303.12.camel@goldbach>
References: <462B6CEB.4010109@lelarge.info>
<1177450739.16415.249.camel@localhost.localdomain>
<1177625227.6440.61.camel@localhost.localdomain>
<1178216419.18303.12.camel@goldbach>
Neil Conway <neilc@samurai.com> writes:
> On Thu, 2007-26-04 at 18:07 -0400, Neil Conway wrote:
>> (1) I believe the reasoning for Tom's earlier change was not to reduce
>> the I/O between the backend and the pgstat process [...]
> Tom, any comments on this? Your change introduced an undocumented
> regression into 8.2. I think you're on the hook for a documentation
> update at the very least, if not a revert.
The documentation update seems the most prudent thing to me. The
problem with the prior behavior is that it guarantees that every table
in the database will eventually have a pg_stat entry, even if
stats_row_level and stats_block_level are both off. In a DB with lots
of tables that creates a significant overhead *for a feature the DBA
probably thinks is turned off*. This is not how it worked before 8.2,
and so 8.2.0's behavior is arguably a performance regression compared
to 8.1 and before.
Now this patch went in before we realized that 8.2.x had a bug in
computing the stats-file-update delay, and it could be that after fixing
that the problem is not so pressing. But I don't particularly care for
new features that impose a performance penalty on those who aren't using
them, and that's exactly what last_vacuum/last_analyze tracking does if
we allow it to bloat the stats file in the default configuration.
The long-term answer of course is to devise a more efficient stats
reporting scheme, but I'm not sure offhand what that would look like.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, neilc@samurai.com, guillaume@lelarge.info
Subject: Re: row-level stats and last analyze time
In-Reply-To: <18709.1178501121@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox