> *light bulb* Ahhh, that's it. So, I guess the solution is either
> to cast the column or wait for 8.3 (which isn't a problem since the
> port won't be done until 8.3 is released anyway).
Just a quick bit of follow-up:
This query works and is equivalent to what I was trying to do (minus
the
> > Hmm - why is it doing that?
>
> I'm betting that the OP's people.uid column is not an integer. Existing
> PG releases can't use hashed subplans for cross-data-type comparisons
> (8.3 will be a bit smarter).
*light bulb* Ahhh, that's it. So, I guess the solution is either
to cast the colum
Tom Lane wrote:
Richard Huxton <[EMAIL PROTECTED]> writes:
Hmm - why is it doing that?
I'm betting that the OP's people.uid column is not an integer. Existing
PG releases can't use hashed subplans for cross-data-type comparisons
(8.3 will be a bit smarter).
Looked like an int2 to me (width=
Richard Huxton <[EMAIL PROTECTED]> writes:
> Hmm - why is it doing that?
I'm betting that the OP's people.uid column is not an integer. Existing
PG releases can't use hashed subplans for cross-data-type comparisons
(8.3 will be a bit smarter).
regards, tom lane
-
Peter Koczan wrote:
Hello,
I have a weird performance issue with a query I'm testing. Basically,
I'm trying to port a function that generates user uids, and since
postgres offers a sequence generator function, I figure I'd take
advantage of that. Basically, I generate our uid range, filter out
t
Hello,
I have a weird performance issue with a query I'm testing. Basically,
I'm trying to port a function that generates user uids, and since
postgres offers a sequence generator function, I figure I'd take
advantage of that. Basically, I generate our uid range, filter out
those which are in use,
