FAQ

A couple months back I wrote:
"Eric Thompson" <eric.thompson@salliemae.com> writes:
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

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedMay 10, '09 at 11:27p
activeMay 10, '09 at 11:27p
posts1
users1
websitepostgresql.org...
irc#postgresql

1 user in discussion

Tom Lane: 1 post

People

Translate

site design / logo © 2021 Grokbase