> Apart from avoiding views or subselects when sorting afterwards and
> putting the whole bunch in a huge SQL statement (which i'll have to
> produce on-the-fly), do you have an other alternative?
> The 2 seconds is way to much, as the database will eventually run on a
> machine that is 10 times slower.
Something that isn't _totally_ clear is whether or not it is going to
be possible to make use of indices in the selection. If the postmaster
must assemble, out of disparate sources, a large collection of data,
the best trade-off may very well be to build the collection the best
way the system knows how (perhaps NOT ordering this using the index you
expect), and sort it afterwards.
Sorting doesn't tend to be grieviously expensive except when finding
the query results is also grieviously expensive.
I think you are assuming that the query would be quicker if it used the
sorted index; that is an assumption that should be checked at the door,
or at least checked somewhere.
--
"The main difference between an amateur crypto designer and a used car
salesman is that the used car salesman can probably drive and knows
when he's lying." -- An Metet <[EMAIL PROTECTED]>
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
