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

A couple months back I wrote:
> "Eric Thompson" <eric(dot)thompson(at)salliemae(dot)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