Re: BUG #4721: All sub-tables incorrectly included in search plan for partitioned table

Interesting... it looks like there is a balance between CPU cycles and disk I/O. I set the MAX_BRANCHES_TO_TEST to 120 and recompiled, so for me everything is fast again. I do not know everything involved, but if there was a way to flag the constraints used for partitioning and always check those to avoid scanning child tables, that may help. Thank you for the quick feedback, and I am happy that I could achieve a quick resolution.

Thanks again,
Eric

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Saturday, March 21, 2009 1:44 AM
To: Thompson, Eric
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: [BUGS] BUG #4721: All sub-tables incorrectly included in search plan for partitioned table

"Eric Thompson" <eric(dot)thompson(at)salliemae(dot)com> writes:
> test=# -- remove any irrelevant constraint from the master table, and now
> the date partitioning works

Hmm. Tracing through this, it seems your child tables have exactly 101
separate constraint clauses; removing one from the parent table gets it
down to 100. Which is where the cutoff installed by this patch is:

http://archives.postgresql.org/pgsql-committers/2008-11/msg00146.php

That patch was in response to this complaint:

http://archives.postgresql.org/pgsql-general/2008-11/msg00446.php

I'm not entirely sure about a better approach; just moving the cutoff
around doesn't seem like it will do anything except change who's
complaining...

regards, tom lane

This E-Mail has been scanned for viruses.