| From: | "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: sort_mem statistics ... |
| Date: | 2005-10-26 21:50:49 |
| Message-ID: | 20051026184945.J993@ganymede.hub.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 26 Oct 2005, Jim C. Nasby wrote:
> On Tue, Oct 18, 2005 at 06:15:02PM -0400, Tom Lane wrote:
>> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
>>> do we maintain anything anywhere for this? mainly, some way of
>>> determining # of 'sorts to disk' vs 'sort in memory', to determine whether
>>> or not sort_mem is set to a good value?
>>
>> As of 8.1 you could turn on trace_sort to collect some data about this.
>
> While trace_sort is good, it doesn't really help for monitoring. What I
> would find useful would be statistics along the lines of:
>
> How many sorts have occured?
> How many spilled to disk?
> What's the largest amount of memory used by an in-memory sort?
> What's the largest amount of memory used by an on-disk sort?
Actually, I'd like to see largest/smallest and average in this ... but if
all is being logged to syslog, I can easily determine those #s with a perl
script ..
----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim C. Nasby | 2005-10-26 21:56:11 | Re: determining random_page_cost value |
| Previous Message | Tom Lane | 2005-10-26 21:47:15 | Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)", File: "nbtsearch.c", Line: 89) |