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:t...@sss.pgh.pa.us] 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 search plan for partitioned table "Eric Thompson" <eric.thomp...@salliemae.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. -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
