On Tue, 2007-01-30 at 17:34 -0500, Tom Lane wrote:
> I think the NOT IN optimization that *would* be of use is to
> automatically transform the NOT IN representation to an
> outer-join-with-null-test type of operation, so as to give us a wider
> choice of join methods. However, I'm not sure about
--On Dienstag, Januar 30, 2007 23:24:40 + Simon Riggs
<[EMAIL PROTECTED]> wrote:
Basically what I see here is a whole lot of work and new executor
infrastructure for something that will be a win in a very narrow
use-case and a significant loss the rest of the time. I think there
are more pro
On Tue, 2007-01-30 at 18:06 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > What would be wrong with checking for a NOT NULL constraint? Thats how
> > other planners cope with it. Or are you thinking about lack of plan
> > invalidation?
>
> Yup, without that, depending on co
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Tue, 2007-01-30 at 17:34 -0500, Tom Lane wrote:
>> Since that is unlikely to be the case, I can't see that this is worth
>> implementing...
> Integers are typically used as keys...
Yeah, in the form of sequences, so you have a hole for every failed
i
On Tue, 2007-01-30 at 17:34 -0500, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> > First we need to show that the referenced table's PK values are a fully
> > continuous sequence of integers with no gaps.
>
> Since that is unlikely to be the case, I can't see that this is worth
> i
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> First we need to show that the referenced table's PK values are a fully
> continuous sequence of integers with no gaps.
Since that is unlikely to be the case, I can't see that this is worth
implementing...
> I'll describe this using SQL statements, whic
