Thanks to visit codestin.com
Credit goes to postgrespro.com

Re: plan time of MASSIVE partitioning ... - Mailing list pgsql-hackers

* Robert Haas ([email protected]) wrote:
> 2010/9/8 Hans-Jürgen Schönig <[email protected]>:
> > 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;

Have you compared how big the tree gets to the size of the list it's
supposed to be replacing..?
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: plan time of MASSIVE partitioning ...
Next
From: Alvaro Herrera
Date:
Subject: Re: plan time of MASSIVE partitioning ...