Re: plan time of MASSIVE partitioning ...
От | Boszormenyi Zoltan |
---|---|
Тема | Re: plan time of MASSIVE partitioning ... |
Дата | |
Msg-id | 4C87B291.5030106@cybertec.at обсуждение исходный текст |
Ответ на | Re: plan time of MASSIVE partitioning ... (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: plan time of MASSIVE partitioning ...
|
Список | 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 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/
В списке pgsql-hackers по дате отправления: