yeah, we have followed quite a lot of discussion as well ...
and yes, no patches.
as far as this problem is concerned: we are working on a patch and did some prototyping inside the planner already (attached).
the code we have is pretty limited atm (such as checking for a sort clause explicitly and so on - it has no support for windowing related optimizations and so on so far).
the cost model is not our problem - it is a lot easier to read than the code we are fighting with (it is a different level of complexity). i think costs can be handled.
yes, this merging adds some costs for sure. we might see a hell amount of operators being called - but i think given a reasonable number of partitions it is still a lot cheaper than actually resorting ... and, it is a lot more space efficient.
in my practical case i cannot resort because we would simply run out of space. an index scan is expensive but needs no additional sort space ...
and, merge is O(n) which sort is clearly not.
advise is highly appreciated.
In response to
pgsql-hackers by date
|Next:||From: David Christensen||Date: 2010-09-01 15:34:29|
|Subject: permissions bug in RI checks?|
|Previous:||From: David E. Wheeler||Date: 2010-09-01 15:16:41|
|Subject: Re: array_agg() NULL Handling|