From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Andreas Karlsson <andreas(at)proxel(dot)se> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PoC: Partial sort |
Date: | 2013-12-18 12:02:05 |
Message-ID: | CAPpHfduz+oA8ioSvh87bmFYbVF=x4==_E3u6wfn-gK1zwx9+_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Dec 14, 2013 at 11:47 PM, Andreas Karlsson <andreas(at)proxel(dot)se>wrote:
> On 12/14/2013 10:59 AM, Alexander Korotkov wrote:
>
>> This patch allows to use index for order-by if order-by clause and index
>> has non-empty common prefix. So, index gives right ordering for first n
>> order-by columns. In order to provide right order for rest m columns,
>> sort node is inserted. This sort node sorts groups of tuples where
>> values of first n order-by columns are equal.
>>
>
> I recently looked at the same problem. I see that you solved the
> rescanning problem by simply forcing the sort to be redone on
> ExecReScanSort if you have done a partial sort.
>
Naturally, I'm sure I solved it at all :) I just get version of patch
working for very limited use-cases.
> My idea for a solution was to modify tuplesort to allow storing the
> already sorted keys in either memtuples or the sort result file, but
> setting a field so it does not sort thee already sorted tuples again. This
> would allow the rescan to work as it used to, but I am unsure how clean or
> ugly this code would be. Was this something you considered?
I'm not sure. I believe that best answer depends on particular parameter:
how much memory we've for sort, how expensive is underlying node and how it
performs rescan, how big are groups in partial sort.
------
With best regards,
Alexander Korotkov.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-12-18 12:07:16 | Re: commit fest 2013-11 final report |
Previous Message | Heikki Linnakangas | 2013-12-18 11:59:12 | Re: [PATCH] SQL assertions prototype |