Re: plan time of MASSIVE partitioning ...
От | Boszormenyi Zoltan |
---|---|
Тема | Re: plan time of MASSIVE partitioning ... |
Дата | |
Msg-id | 4C87B27B.3010002@cybertec.at обсуждение исходный текст |
Ответ на | Re: plan time of MASSIVE partitioning ... (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-hackers |
Stephen Frost írta: > * Robert Haas (robertmhaas@gmail.com) wrote: > >> 2010/9/8 Hans-Jürgen Schönig <postgres@cybertec.at>: >> >>> 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. >>> >> Just remember that four small patches (say) are apt to get committed >> faster than one big one. >> > > Indeed, but code like this makes me wonder if this is really working the > way it's supposed to: > > + val1 = (long)pk_left->pk_eclass; > + val2 = (long)pk_right->pk_eclass; > + > + if (val1 < val2) > + return -1; > + else if (val1 > val2) > + return 1; > The original code checked for pointers being equal among other conditions. This was an (almost) straight conversion to a comparison function for rbtree. Do you mean casting the pointer to long? Yes, e.g. on 64-bit Windows it wouldn't work. Back to plain pointer comparison. > Have you compared how big the tree gets to the size of the list it's > supposed to be replacing..? > No, but I think it's obvious. Now we have one TreeCell where we had one ListCell. 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 по дате отправления: