Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] row-level stats and last analyze time

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Guillaume Lelarge <guillaume(at)lelarge(dot)info>, pgsql-docs(at)postgresql(dot)org, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] row-level stats and last analyze time
Date: 2007-05-16 15:15:09
Message-ID: 200705161515.l4GFF9T03064@momjian.us (view raw or flat)
Thread:
Lists: pgsql-docspgsql-hackers
Has this been done yet?  I don't think so.

---------------------------------------------------------------------------

Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
> 
>                 http://www.postgresql.org/about/donate

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-docs by date

Next:From: Andrew DunstanDate: 2007-05-16 15:22:11
Subject: Re: [PATCHES] OS/X startup scripts
Previous:From: David FetterDate: 2007-05-16 14:59:36
Subject: Re: [PATCHES] OS/X startup scripts

pgsql-hackers by date

Next:From: David FetterDate: 2007-05-16 15:19:34
Subject: Re: Testing concurrent psql
Previous:From: Robert HaasDate: 2007-05-16 15:13:31
Subject: Re: Not ready for 8.3

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group