Alvaro Herrera írta:
> Excerpts from Stephen Frost's message of mié sep 08 11:26:55 -0400 2010:
>> * Hans-Jürgen Schönig ( 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

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to