From: | "Scott Marlowe" <smarlowe(at)qwest(dot)net> |
---|---|
To: | "Shane | SkinnyCorp" <shanew(at)skinnycorp(dot)com> |
Cc: | "PgSQL ADMIN" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: PLEASE GOD HELP US! |
Date: | 2004-10-02 04:33:36 |
Message-ID: | 1096691616.2611.22.camel@localhost.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Fri, 2004-10-01 at 14:26, Shane | SkinnyCorp wrote:
> Okay, just so no one posts about this again...
>
> the 'ORDER BY t.status=5,lastreply' clause is meant to float the threads
> with a status of '5' to the top of the list... it is NOT meant to only grab
> threads where the status = 5. Oh and believe me, when I take this out of
> the query, it CERTAINLY doesn't add any more than possible 1/4 of a
> millesecond to the speed of the SELECT statement.
Wouldn't this work just as well?
SELECT * FROM thread_listing AS t ORDER BY t.status
DESC,t.lastreply desc LIMIT 25 OFFSET 0
Assuming 5 is the highest number. If not, a where clause entry might
make sense.
SELECT * FROM thread_listing AS t
WHERE t.status <= 5
ORDER BY t.status
DESC,t.lastreply desc LIMIT 25 OFFSET 0
Or is the data set put together some weird way that makes that
impossible?
From | Date | Subject | |
---|---|---|---|
Next Message | John McBride | 2004-10-02 10:29:28 | Re: fedora core 2 postgresql regression tests fail |
Previous Message | William Yu | 2004-10-02 02:15:42 | Re: PLEASE GOD HELP US! |