Thread: Re: [BUGS] BUG #4721: All sub-tables incorrectly included in search plan for partitioned table
Re: [BUGS] BUG #4721: All sub-tables incorrectly included in search plan for partitioned table
From
Tom Lane
Date:
A couple months back I wrote: > "Eric Thompson" <eric.thompson@salliemae.com> writes: >> [ http://archives.postgresql.org//pgsql-bugs/2009-03/msg00116.php ] > 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... I spent some more time chewing on this. I still don't see a good solution to detect and avoid the repeated determinations that "x <> const1" can't refute "x <> const2". It seems possible to do but it would uglify the code in predtest.c tremendously. The best thing I can think of that seems practical (especially as a back-patch) is just to rejigger the complexity cutoff installed by the above-mentioned patch. Since the cases that are known to be objectionable involve long IN-lists (ie, ScalarArrayOpExpr with a large array), what I'm considering doing is reverting the patch for all but that case --- ie, have a complexity limit only for ScalarArrayOpExpr. Comments? regards, tom lane