From: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plan time of MASSIVE partitioning ... |
Date: | 2010-09-08 15:57:47 |
Message-ID: | 4C87B27B.3010002@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stephen Frost írta:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>
>> 2010/9/8 Hans-Jürgen Schönig <postgres(at)cybertec(dot)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 that more 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/
From | Date | Subject | |
---|---|---|---|
Next Message | Boszormenyi Zoltan | 2010-09-08 15:58:09 | Re: plan time of MASSIVE partitioning ... |
Previous Message | Tom Lane | 2010-09-08 15:42:14 | Re: plan time of MASSIVE partitioning ... |