Horton

Re: plan time of MASSIVE partitioning ...

Boszormenyi Zoltan <zb@cybertec.at>

View thread
From: Boszormenyi Zoltan <zb@cybertec.at>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Stephen Frost <sfrost@snowman.net>, Hans-Jürgen Schönig <postgres@cybertec.at>, Robert Haas <robertmhaas@gmail.com>, pgsql-hackers Hackers <pgsql-hackers@postgresql.org>
Date: 2010-09-10T09:14:41Z
Lists: pgsql-hackers

Attachments

Tom Lane írta:
> Boszormenyi Zoltan <zb@cybertec.at> writes:
>   
>> equal() is called over 8 million times with or without our patch:
>>     
>
> From where, though?  You've provided not a shred of evidence that
> searching large ec_member lists is the problem.
>   

Indeed. I have put elog(NOTICE) calls in there to see which
lists is how long. It turned out that the length of ec_members is either 0
or 1, mostly 1, but the length of eq_classes is constantly growing.
This is what I need to attack then.

> Also, did the test case you're using ever make it to the list?
>   

No, because it was too large and because of the test case
accidentally contained confidential information, we asked
Bruce to delete it from the moderator queue.

Attached is a shortened test case that does the same and
also shows the same problem. The create_table.sql
creates the parent table, the table_generator.sql produces
the list of constraint excluded child tables and their indexes.

The gprof output of this is only slightly modified, the
number of equal() calls is still over 8 million, it is also
attached.

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/