Date: Fri, 06 Jun 2008 16:29:12 -0500
From: Robert Lor <Robert.Lor@Sun.COM>
Subject: Re: Overhauling GUCS
In-reply-to: <200806061541.36984.xzilla@users.sourceforge.net>
To: Robert Treat <xzilla@users.sourceforge.net>
Cc: pgsql-hackers@postgresql.org, Greg Smith <gsmith@gregsmith.com>,
	Aidan Van Dyk <aidan@highrise.ca>
Message-id: <4849AC28.4060801@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <48409D1E.3070208@agliodbs.com>
	<20080605011455.GF14498@yugib.highrise.ca>
	<Pine.GSO.4.64.0806042134090.3874@westnet.com>
	<200806061541.36984.xzilla@users.sourceforge.net>
User-Agent: Thunderbird 2.0.0.6 (X11/20071119)

Robert Treat wrote:
> On Wednesday 04 June 2008 22:04:54 Greg Smith wrote:
>   
>> I was just talking to someone today about building a monitoring tool for
>> this.  Not having a clear way to recommend people monitor use of work_mem
>> and its brother spilled to disk sorts is an issue right now, I'll whack
>> that one myself if someone doesn't beat me to it before I get time.
>>     
>
> I remember *years* ago, someone wrote a perl script to poll pgsql_tmp and 
> print out anytime something showed up... you could probably find that in the 
> archives if you look around. 
>
> of course to me this sounds like an excellent idea for a dtrace probe ;-)
>
>   

Actually, you can find out from the sort-end probe now whether or not 
the sort spilled to disk and number of disk blocks used. This is one of 
the probes from Simon.

TRACE_POSTGRESQL_SORT_END(state->tapeset,
                        (state->tapeset ? 
LogicalTapeSetBlocks(state->tapeset) :
                        (state->allowedMem - state->availMem + 1023) / 
1024));

-Robert