On Mon, Dec 21, 2009 at 11:43 AM, Pavel Stehule wrote:
>> If we don't find a way to optimize this for on-disk tuplestores though
>> then I wonder whether it's worth it. It would only help in the narrow
>> case that you had a large enough set to see the difference between
>> doing quickselect and q
2009/12/21 Greg Stark :
> On Mon, Dec 21, 2009 at 5:48 AM, Pavel Stehule
> wrote:
>> Information about count of rows are not detected in planner time. This
>> have to by available in any executor's sort node. So this value will
>> be available every time - index scan is problem. Interesting is G
On Mon, Dec 21, 2009 at 5:48 AM, Pavel Stehule wrote:
> Information about count of rows are not detected in planner time. This
> have to by available in any executor's sort node. So this value will
> be available every time - index scan is problem. Interesting is Greg's
> info about O(N) algorith
2009/12/21 Greg Stark :
> Incidentally there are O(n) algorithms for finding the median (or any
> specific offset). It shouldn't be necessary to sort at all.
it is interesting information. It could to help with missing
optimalisations now.
Pavel
>
> I'm not sure which path this argues for - perh
Incidentally there are O(n) algorithms for finding the median (or any
specific offset). It shouldn't be necessary to sort at all.
I'm not sure which path this argues for - perhaps Tom's position that
we need more optimiser infrastructure so we can see how to accomplish
this. Perhaps it means you s
