Re: [GENERAL] Very slow queries w/ NOT IN preparation (seems like a bug, test case) - Mailing list pgsql-hackers

From Brendan Jurd
Subject Re: [GENERAL] Very slow queries w/ NOT IN preparation (seems like a bug, test case)
Date
Msg-id 37ed240d0811121034i6b0ac02cs2a8e6955edb64926@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] Very slow queries w/ NOT IN preparation (seems like a bug, test case)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Nov 13, 2008 at 5:16 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Brendan Jurd" <direvus@gmail.com> writes:
>> I guess my question is, what's the real benefit of going to all this
>> trouble trying to prove that clauses are false?
>
> Not having to scan gigabytes of data in an excluded partition, for
> instance.

[after RTFMing ...]

The docs also say:

"When this parameter is on, the planner compares query conditions with
table CHECK constraints, and omits scanning tables for which the
conditions contradict the constraints."

I would normally interpret the above to mean that the planner *only*
performs these checks where a table CHECK constraint is relevant.  I
dug up the original test case posted by Sergey, and his test table
didn't have any CHECK constraint on it at all (unless you count the
NOT NULL implied by PRIMARY KEY).

Cheers,
BJ


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [GENERAL] Very slow queries w/ NOT IN preparation (seems like a bug, test case)
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Very slow queries w/ NOT IN preparation (seems like a bug, test case)