Re: Query plan for NOT IN - Mailing list pgsql-performance

From Craig James
Subject Re: Query plan for NOT IN
Date
Msg-id 4ACCF9C9.8040102@emolecules.com
Whole thread Raw
In response to Re: Query plan for NOT IN  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Query plan for NOT IN  (Guy Rouillier <guyr-ml1@burntmail.com>)
List pgsql-performance
Kevin Grittner wrote:
> Which leaves the issue open -- a flexible way to flag the *reason* (or
> *reasons*) for the absence of a value could be a nice enhancement, if
> someone could invent a good implementation.  Of course, one could
> always add a column to indicate the reason for a NULL; and perhaps
> that would be as good as any scheme to attach reason flags to NULL.
> You'd just have to make sure the reason column was null capable for
> those rows where there *was* a value, which would make the reason "not
> applicable"....

I'd argue that this is just a special case of a broader problem of metadata: Data about the data.  For example, I could
havea temperature, 40 degrees, and an error bounds, +/- 0.25 degrees.  Nobody would think twice about making these
separatecolumns.  I don't see how this is any different from a person's middle initial of NULL, plus a separate column
indicating"not known" versus "doesn't have one" if that distinction is important.  There are many examples like this,
wherea simple value in one column isn't sufficient, so another column contains metadata that qualifies or clarifies the
information. NULL is just one such case. 

But, this should probably be on an SQL discussion board, not PG performance...

Craig

pgsql-performance by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: Query plan for NOT IN
Next
From: Guy Rouillier
Date:
Subject: Re: Query plan for NOT IN