On Sun, 3 Oct 2004, Gaetano Mendola wrote:
> Scott Marlowe wrote:
> > On Sat, 2004-10-02 at 09:14, Stephan Szabo wrote:
> >
> >>On Fri, 1 Oct 2004, Scott Marlowe wrote:
> >>
> >>
> >>>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
> >>
> >>Probably not, because I don't think he wants the other statuses to have
> >>special ranking over the others, so a status=4 and status=1 row should be
> >>sorted by lastreply only effectively. This is the problem of combining
> >>separate status flags into a single field if you want to be doing these
> >>sorts of queries.
> >>
> >
> >
> > So would a union give good performance? Just union the first 25 or less
> > with status=5 with the rest, using a 1 and 0 in each union to order by
> > first? Hopefully the indexes would then be used.
>
> anyone seen that the OP is running the server with sequential scan disabled ?
Yep, but he's doing some queries for which the indexes weren't useful
unless he had some very specific ones, so it'd still be choosing
sequential scans for those AFAICT (for example I believe the 9s get the
first 25 threads query).
I think someone'd already pointed out that running with sequential scan
disabled is generally a bad idea, so I didn't think it was worth
mentioning again.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
