Michael Fuhr wrote:
>
> It's not clear how you'd use a sort order to run concurrent queries,
> nor how that involves how many rows you'd have to fetch. Could you
> elaborate? But it might be better to post the query and the EXPLAIN
> ANALYZE output and let others take a look: let's examine the problem
> before thinking about a solution.
>
I should have been a bit more clear on the matter. Order by is useful
if you want to sort the dataset a specific way using rows. However,
what if I wanted to specify the order the rows are returned in using
information from another query?
While I could post table definitions, explain analyze information and
sample data it probably is not all that useful. Lets just say that
this three-way join is mixing a reverse index with two other tables.
So trying to mix in VERY large datasets into one another with SUM and
COUNT thrown in creates a nasty situation even if I would normally pick
up at the most 100 rows.
So my solution is to simplify matters and cut down the dataset used
almost immediately. Even with say 24 secondary queries to fetch
specific information this process is probably a lot cleaner?
Martin Foster
Creator/Designer Ethereal Realms
martin@ethereal-realms.org
