Re: plan time of MASSIVE partitioning ...

Boszormenyi Zoltan <zb@cybertec.at>

From: Boszormenyi Zoltan <zb@cybertec.at>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Stephen Frost <sfrost@snowman.net>, Hans-Jürgen Schönig <postgres@cybertec.at>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers Hackers <pgsql-hackers@postgresql.org>
Date: 2010-09-08T15:58:09Z
Lists: pgsql-hackers
Alvaro Herrera írta:
> Excerpts from Stephen Frost's message of mié sep 08 11:26:55 -0400 2010:
>   
>> * Hans-Jürgen Schönig (postgres@cybertec.at) wrote:
>>     
>>> but, it seems the problem we are looking is not sufficiently fixed yet.
>>> in our case we shaved off some 18% of planning time or so - looking at the other top 2 functions i got the feeling that more can be done to reduce this. i guess we have to attack this as well.
>>>       
>> An 18% increase is certainly nice, provided it doesn't slow down or
>> break other things..  I'm looking through the patch now actually and
>> I'm not really happy with the naming, comments, or some of the code
>> flow, but I think the concept looks reasonable.
>>     
>
> I don't understand the layering between pg_tree and rbtree.  Why does it
> exist at all?  At first I thought this was another implementation of
> rbtrees, but then I noticed it sits on top of it.  Is this really
> necessary?
>   

No, if it's acceptable to omit PlannerInfo from outfuncs.c.
Or at least its canon_pathkeys member. Otherwise yes, it's
necessary. We need to store (Node *) in a fast searchable way.

This applies to anything else that may need to be converted
from list to tree to decrease planning time. Like ec_members
in EquivalenceClass.

Best regards,
Zoltán Böszörményi

-- 
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
     http://www.postgresql.at/