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

Gregory Stark wrote:
> "Magnus Hagander" <magnus(at)hagander(dot)net> writes:
>
>>> What 3 columns? In-memory sorts, on-disk sorts, and on-disk size?
>>> (Sum of how much spilled to disk).
>> I was thinking in-mem sorts, on-disk sorts, limited-by-LIMIT sorts (that
>> would be the new feature..)
>
> Tom's code distinguished in-memory, top-N, on-disk with final merge postponed,
> and on-disk with materialized result. Four categories. But I think the
> distinction between the two types of in-memory and the two types of on-disk
> sorts is only really useful when you're looking at an individual query. And
> even then probably only useful to a Postgres hacker, not a DBA.

Missed the two on-disk distinctions, yeah. But you're probably right
that on-disk vs in-memory is enough, the interesting thing is to get
indications on when you hit disk given what it does for performance.

> It seems like it would be more useful to just break it down into in-memory and
> on-disk but for each give number of sorts, number of tuples, and space used.
>
> What would be really handy is breaking this down by table -- probably that
> would only be possible when the sort is sorting directly a table scan. I don't
> even know how easy it would be to get that information.

And how would you deal with the data that's sorting the result of a join
or something like that - makes things a lot more complicated ;)

And the original question remains, 8.3 or 8.4...

//Magnus