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
thatmore 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/