Interesting... it looks like there is a balance between CPU cycles and dis=
k I/O. I set the MAX_BRANCHES_TO_TEST to 120 and recompiled, so for me eve=
rything is fast again. I do not know everything involved, but if there wa=
s a way to flag the constraints used for partitioning and always check thos=
e to avoid scanning child tables, that may help. Thank you for the quick f=
eedback, and I am happy that I could achieve a quick resolution.
Thanks again,
Eric
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]=20
Sent: Saturday, March 21, 2009 1:44 AM
To: Thompson, Eric
Cc: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #4721: All sub-tables incorrectly included in searc=
h plan for partitioned table=20
"Eric Thompson" <eric.thompson@salliemae.com> writes:
> test=3D# -- remove any irrelevant constraint from the master table, and n=
ow
> the date partitioning works=20
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.