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 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.