From: Matthew T. O'Connor <matthew@zeut.net>
To: Mikael Carneholm <Mikael.Carneholm@WirelessCar.com>
Cc: Postgresql Performance <pgsql-performance@postgresql.org>
Subject: Re: count(*) performance
Date: Mon, 27 Mar 2006 17:43:02 -0500
Message-ID: <44286A76.5010008@zeut.net> (raw)
In-Reply-To: <7F10D26ECFA1FB458B89C5B4B0D72C2B088295@sesrv12.wirelesscar.com>
References: <7F10D26ECFA1FB458B89C5B4B0D72C2B088295@sesrv12.wirelesscar.com>
Mikael Carneholm wrote:
> This is where a "last_vacuumed" (and "last_analyzed") column in
> pg_statistic(?) would come in handy. Each time vacuum or analyze has
> finished, update the row for the specific table that was
> vacuumed/analyzed with a timestamp in the last_vacuumed/last_analyzed
> column. No more guessing "maybe I haven't vacuumed/analyzed in a while",
> and each time a user complains about bad performance, one could request
> the user to do a "select s.last_vacuumed, s.last_analyzed from
> pg_statistic s, pg_attribute a, pg_class c where ..."
>
> It SOUNDS easy to implement, but that has fooled me before... :-)
It is fairly easy to implement, however it has been discussed before and
decided that it wasn't necessary. What the system cares about is how
long it's been since the last vacuum in terms of XIDs not time. Storing
a timestamp would make it more human readable, but I'm not sure the
powers that be want to add two new columns to some system table to
accommodate this.
Matt
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-performance@postgresql.org
Cc: matthew@zeut.net, Mikael.Carneholm@WirelessCar.com
Subject: Re: count(*) performance
In-Reply-To: <44286A76.5010008@zeut.net>
* 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