Re: plan time of MASSIVE partitioning ...
От | Boszormenyi Zoltan |
---|---|
Тема | Re: plan time of MASSIVE partitioning ... |
Дата | |
Msg-id | 4CC95683.4020101@cybertec.at обсуждение исходный текст |
Ответ на | Re: plan time of MASSIVE partitioning ... (Boszormenyi Zoltan <zb@cybertec.at>) |
Ответы |
Re: plan time of MASSIVE partitioning ...
Re: plan time of MASSIVE partitioning ... |
Список | pgsql-hackers |
Boszormenyi Zoltan írta: > Boszormenyi Zoltan írta: > >> Heikki Linnakangas írta: >> >> >>> On 26.10.2010 18:34, Boszormenyi Zoltan wrote: >>> >>> >>>> thank you very much for pointing me to dynahash, here is the >>>> next version that finally seems to work. >>>> >>>> Two patches are attached, the first is the absolute minimum for >>>> making it work, this still has the Tree type for canon_pathkeys >>>> and eq_classes got the same treatment as join_rel_list/join_rel_hash >>>> has in the current sources: if the list grows larger than 32, a hash >>>> table >>>> is created. It seems to be be enough for doing in for >>>> get_eclass_for_sort_expr() >>>> only, the other users of eq_classes aren't bothered by this change. >>>> >>>> >>> That's better, but can't you use dynahash for canon_pathkeys as well? >>> >>> >> Here's a purely dynahash solution. It's somewhat slower than >> the tree version, 0.45 vs 0.41 seconds in the cached case for the >> previously posted test case. >> >> > > And now in context diff, sorry for my affection towards unified diffs. :-) > A little better version, no need for the heavy hash_any, hash_uint32 on the lower 32 bits on pk_eclass is enough. The profiling runtime is now 0.42 seconds vs the previous 0.41 seconds for the tree version. 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 по дате отправления: