here is the patch again. we accidentally attached a wrong test file to the original posting so it grew to big. we had to revoke it from the moderator (this happens if you code from 8am to 10pm). here is just the patch - it is nice and small.
you can easily test it by making yourself a nice parent table, many subtables (hundreds or thousands) and a decent number of indexes per partition. then run PREPARE with \timing to see what happens. you should get scary planning times. the more potential indexes and tables the more scary it will be. using this wonderful RB tree the time for this function call goes down to basically zero. i hope this is something which is useful to some folks out there. many thanks, hans
Description: Binary data
On Sep 8, 2010, at 4:18 PM, Stephen Frost wrote: > * Hans-Jürgen Schönig (postg...@cybertec.at) wrote: >> no, we have not checked memory consumption. >> there is still some stuff left to optimize away - it seems we are going >> close to O(n^2) somewhere. >> "equal" is called really often in our sample case as well: > > Did the mail with the scripts, etc, get hung up due to size or > something..? I didn't see it on the mailing list nor in the archives.. > If so, could you post them somewhere so others could look..? > > Thanks, > > Stephen -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de
-- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers