From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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:47:35 |
Message-ID: | 20070504164735.GF30617@svr2.hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Fri, May 04, 2007 at 12:38:18PM -0400, Tom Lane wrote:
> 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.
Now that you mention it, that'd be nice to have as well - the point being
making it available without recompile.
> 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.
Hmm. Ok. Don't know enough about those parts of the code to comment on
that, but I'll certainly take your word for it :-)
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-05-04 17:08:18 | Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first |
Previous Message | Gregory Stark | 2007-05-04 16:46:54 | Re: pgsql: Teach tuplesort.c about "top N" sorting, in which only the first |
From | Date | Subject | |
---|---|---|---|
Next Message | Ale Raza | 2007-05-04 16:57:58 | Re: Where to find kind code for STATISTIC_KIND GEOMETRY? |
Previous Message | Gregory Stark | 2007-05-04 16:46:54 | Re: pgsql: Teach tuplesort.c about "top N" sorting, in which only the first |