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
