Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first
Date
Msg-id 0EFB5D10-9975-437C-BBC8-456E8375F98B@decibel.org
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first
List pgsql-hackers
On May 4, 2007, at 7:49 PM, Tom Lane wrote:
> Jim Nasby <decibel@decibel.org> writes:
>> On a related note, it would also be *really* nice if we kept stats on
>> how many sorts or hashes had spilled to disk, perhaps along with how
>> much had spilled. Right now the only way to monitor that in a
>> production system is to setup a cron job to watch pgsql_tmp, which is
>> far from elegant.
>
> No, you can turn on trace_sort and track it from watching the log.
> If pgfouine hasn't got something for that already, I'd be surprised.

There's several problems with that. First, trace_sort isn't  
documented (or at least it's not in postgresql.conf), so most folks  
don't know it exists. Second, in order to see it's output you have to  
drop log_min_messages to debug. That results in a huge log volume,  
especially on a production system.

Aside from that, log files are not a good way to monitor performance,  
they should be used for reporting on exception conditions. If the log  
was meant to be the means for monitoring performance, then why have  
the statistics system at all?

As for pgfouine, I've never been to a customer that knew what it was.  
But almost all of them have other monitoring tools such as cricket,  
MRTG and Nagios setup. Those that don't at least know they exist.
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Managing the community information stream
Next
From: Jim Nasby
Date:
Subject: Re: temporal variants of generate_series()