Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first
От | Gregory Stark |
---|---|
Тема | Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first |
Дата | |
Msg-id | 876472gca7.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N" sorting, in which only the first (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: [COMMITTERS] pgsql: Teach tuplesort.c about "top N"
sorting, in which only the first
|
Список | pgsql-hackers |
"Magnus Hagander" <magnus@hagander.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. 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. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: