From: | Jeremy Harris <jgh(at)wizmail(dot)org> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PoC: Partial sort |
Date: | 2014-01-18 19:13:36 |
Message-ID: | 52DAD260.3080001@wizmail.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 31/12/13 01:41, Andreas Karlsson wrote:
> On 12/29/2013 08:24 AM, David Rowley wrote:
>> If it was possible to devise some way to reuse any
>> previous tuplesortstate perhaps just inventing a reset method which
>> clears out tuples, then we could see performance exceed the standard
>> seqscan -> sort. The code the way it is seems to lookup the sort
>> functions from the syscache for each group then allocate some sort
>> space, so quite a bit of time is also spent in palloc0() and pfree()
>>
>> If it was not possible to do this then maybe adding a cost to the number
>> of sort groups would be better so that the optimization is skipped if
>> there are too many sort groups.
>
> It should be possible. I have hacked a quick proof of concept for
> reusing the tuplesort state. Can you try it and see if the performance
> regression is fixed by this?
>
> One thing which have to be fixed with my patch is that we probably want
> to close the tuplesort once we have returned the last tuple from
> ExecSort().
>
> I have attached my patch and the incremental patch on Alexander's patch.
How does this work in combination with randomAccess ?
--
Thanks,
Jeremy
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2014-01-18 19:45:23 | Re: Race condition in b-tree page deletion |
Previous Message | Tom Lane | 2014-01-18 18:55:05 | Re: [PATCH] Make various variables read-only (const) |