Alvaro Herrera írta: > Excerpts from Stephen Frost's message of mié sep 08 11:26:55 -0400 2010: > >> * Hans-Jürgen Schönig (postg...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
