From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Magnus Hagander" <magnus(at)hagander(dot)net>, <pgsql-committers(at)postgresql(dot)org> |
Subject: | Re: pgsql: Teach tuplesort.c about "top N" sorting, in which only the first |
Date: | 2007-05-04 16:46:54 |
Message-ID: | 87fy6cilj5.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> Could we show it in EXPLAIN ANALYZE somehow? I'm thinking it would be good
>> to see at runtime (for example as a hint that if you put in a bit more
>> work_mem it might get used)
>
> I don't see that this is any more interesting than whether the sort
> spilled to disk or not; which is something we don't show in EXPLAIN
> ANALYZE either. trace_sort is the agreed API for examining that.
> It's not exactly easy to do, because (a) none of this information
> is exposed outside tuplesort.c, and (b) the tuplesortstate object
> is probably gone by the time EXPLAIN ANALYZE runs, anyway.
It would be positively wonderful to see whether the sort spilled to disk in
the explain analyze. Could we make putting more feedback about sorts in
EXPLAIN ANALYZE output a TODO?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-05-04 16:47:35 | Re: pgsql: Teach tuplesort.c about "top N" sorting, in which only the first |
Previous Message | Tom Lane | 2007-05-04 16:38:18 | Re: pgsql: Teach tuplesort.c about "top N" sorting, in which only the first |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-05-04 16:47:35 | Re: pgsql: Teach tuplesort.c about "top N" sorting, in which only the first |
Previous Message | Tom Lane | 2007-05-04 16:41:29 | Re: Grantor name gets lost when grantor role dropped |