From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
---|---|
To: | Jeremy Harris <jgh(at)wizmail(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
Subject: | Re: PoC: Partial sort |
Date: | 2014-01-19 01:57:03 |
Message-ID: | 52DB30EF.4060506@proxel.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 01/18/2014 08:13 PM, Jeremy Harris wrote:
> 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 ?
As far as I can tell randomAccess was broken by the partial sort patch
even before my change since it would not iterate over multiple
tuplesorts anyway.
Alexander: Is this true or am I missing something?
--
Andreas Karlsson
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2014-01-19 02:17:41 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Previous Message | Andreas Karlsson | 2014-01-19 01:45:06 | Re: GiST support for inet datatypes |