Paul Caskey wrote:
>
> This query takes 206 seconds:
>
> SELECT t1.blah, t1.foo, t2.id
> FROM t1, t2, t3
> WHERE t1.SessionId = 427
> AND t1.CatalogId = 22
> AND t1.CatalogId = t3.CatalogId
> AND t2.id = t3.SomeId
> AND t2.Active != 0
>
> If I change the
field is 0 or 1. The query returns the same rows, either way
(about 1700 rows). There is an index on the Active field.
These two queries both take 1 second:
SELECT * FROM t2 WHERE Active = 1;
SELECT * FROM t2 WHERE Active != 0;
Any ideas? Possible bug?
--
Paul Caskey [EMAIL
erating toward that 4G limit 100 times faster.
Bottom line: I can recycle my own IDs if I have to. But I need to know
whether I should change my table structure and/or code to conserve OIDs,
an internal system identifier particular to the RDBMS I chose.
Considering the main reason I chose Postgr
Tom Lane wrote:
>
> Paul Caskey <[EMAIL PROTECTED]> writes:
>
> >> No doubt about it, you're likely to get a few "duplicate key" errors and
> >> stuff like that. I'm just observing that it's not likely to be a
> >> complete cata
Tom Lane wrote:
>
> Paul Caskey <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> It's only a hard limit if your application assumes OIDs are unique.
> >> If you don't assume that, then I think it's not a big problem.
> >>
> >
Tom Lane wrote:
>
> Chris Bitmead <[EMAIL PROTECTED]> writes:
> > Paul Caskey wrote:
> >> 1. This implies a hard limit of 4 billion records on a server, right?
>
> > Basically, yes.
>
> It's only a hard limit if your application assumes OIDs are u
to mess with the "CREATE SEQUENCE" syntax; it would seem
more appropriate as a compile-time option.
Paul Caskey
Software Engineer
New Mexico Software
