Stephan Szabo <[EMAIL PROTECTED]> writes:
> Well, you have to be careful on the combination to not give the wrong
> answers if there's a row with u.status=3 that matches a row d.status=3.
We could in theory handle that using something similar to the method
currently used for "OR" indexscans (that
Stephan Szabo wrote:
On Mon, 22 Mar 2004, Joseph Shraibman wrote:
Tom Lane wrote:
Joseph Shraibman <[EMAIL PROTECTED]> writes:
No, pkey is not the primary key in this case. The number of entries in u
that have pkey 260 and not boolfield is 344706.
... and every one of those rows *must* be in
On Mon, 22 Mar 2004, Joseph Shraibman wrote:
> Tom Lane wrote:
> > Joseph Shraibman <[EMAIL PROTECTED]> writes:
> >
> >>No, pkey is not the primary key in this case. The number of entries in u
> >>that have pkey 260 and not boolfield is 344706.
> >
> >
> > ... and every one of those rows *must* b
Tom Lane wrote:
Joseph Shraibman <[EMAIL PROTECTED]> writes:
No, pkey is not the primary key in this case. The number of entries in u
that have pkey 260 and not boolfield is 344706.
... and every one of those rows *must* be included in the join input,
*If* you use one big join in the first plac
Joseph Shraibman <[EMAIL PROTECTED]> writes:
> No, pkey is not the primary key in this case. The number of entries in u
> that have pkey 260 and not boolfield is 344706.
... and every one of those rows *must* be included in the join input,
regardless of its status value, because it might join to
Richard Huxton wrote:
On Thursday 18 March 2004 21:21, Joseph Shraibman wrote:
explain
SELECT COUNT(u.ukey) FROM u, d WHERE d.ukey = u.ukey AND u.pkey = 260
AND (u.status = 3 OR d.status = 3 ) AND NOT u.boolfield ;
QUERY PLAN
--
On Thursday 18 March 2004 21:21, Joseph Shraibman wrote:
> explain
> SELECT COUNT(u.ukey) FROM u, d WHERE d.ukey = u.ukey AND u.pkey = 260
> AND (u.status = 3 OR d.status = 3 ) AND NOT u.boolfield ;
>
>
>QUERY PLAN
> --
