hello tom,
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
windowingrelated 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
levelof 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
reasonablenumber 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
additionalsort space ...
and, merge is O(n) which sort is clearly not.
advise is highly appreciated.
many thanks,
hans
On Sep 1, 2010, at 5:00 PM, Tom Lane wrote:
> =?iso-8859-1?Q?PostgreSQL_-_Hans-J=FCrgen_Sch=F6nig?= <postgres@cybertec.at> writes:
>> On Sep 1, 2010, at 4:10 PM, Tom Lane wrote:
>>> This is really premature, and anything you do along those lines now will
>>> probably never get committed.
>
>> well, why non-overlapping? the idea is to make append smart enough to
>> take the sorted lists from below and merge them which will give sorted
>> output as well.
>
> Well, an extra merge step is going to change the cost comparisons quite
> a bit; see Greg Starks' comments. But in any case, my point wasn't that
> this is something we should never do; it was that it makes more sense to
> wait till something has happened with explicit partitioning.
>
>>> The project direction is that we are going to add some explicit
>>> representation of partitioned tables.
>
>> can you outline some ideas here and maybe point to some useful discussion here?
>
> There's been boatloads of discussion of partitioning, and at least one
> submitted patch, over the past year or so ...
>
> regards, tom lane
>
--
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de