On Sat, 2 Oct 2004, 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.
You'd want to use union all I think and you may have to put limits on the
unioned arms to get good behavior. I think the expression index would
probably work without changing the query (at least for relatively low
offsets) at the cost of having an extra index to maintain.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
