Has this been done yet? I don't think so.
---
Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > On Thu, 2007-26-04 at 18:07 -0400, Neil Conway wrote:
> >> (1) I believe the reasoning for Tom's earlier change was
Neil Conway <[EMAIL PROTECTED]> 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
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 hoo
Neil Conway wrote:
> (3) I don't like the fact that the current coding is so willing to throw
> away VACUUM and ANALYZE pgstat messages. I think it is quite plausible
> that the DBA might be interested in the last-VACUUM and last-ANALYZE
> information for a table which hasn't had live operations a
On Tue, 2007-04-24 at 17:38 -0400, Neil Conway wrote:
> which included other modifications to reduce the pgstat I/O volume in
> 8.1. I don't think this particular change was wise
I looked into this a bit further:
(1) I believe the reasoning for Tom's earlier change was not to reduce
the I/O betwe
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 t
