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 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.

        many thanks,

                hans


Attachment: push-down-sort-into-inh-2.patch
Description: Binary data

On Sep 1, 2010, at 5:00 PM, Tom Lane wrote:

> =?iso-8859-1?Q?PostgreSQL_-_Hans-J=FCrgen_Sch=F6nig?= <postg...@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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to