> > You might try a multi-column index on (ms.monitorx, ms.datex). > > Just tried it, it didn't prevent the sort. But it sounds like the sort > isn't the problem, correct?
The sort isn't actually doing any sorting, so it's virtually free. The sort is taking less than 3ms as the data is already 99% sorted due to the correlation between datex and monitorx. For similar reasons, the datex index will not be used, as it has no advantage to being used. > -> Index Scan using > monitorstatusx_datex_monitorx_index on monitorstatusx ms > (cost=0.00..1159.33 rows=890 width=83) (actual time=0.19..1287.02 rows=628 > loops=1) > Index Cond: (("outer".jdoidx = ms.monitorx) > AND (ms.datex >= '2003-06-20 08:57:21.36'::timestamp without time zone) AND > (ms.datex <= '2003-06-29 08:57:21.36'::timestamp without time zone)) You can see that it used the new multi-key index for both items, rather than finding for monitorx, then filtering out unwanted results by datex. It doesn't appear to have made much difference (looks like data was partially cached for this new run), but it changed a bit for the better. I'm afraid thats the best I can do on the query itself I think. Oh, and using tables in your where clause that aren't in the from clause is non-portable and often hides bugs: from monitorstatusx ms , monitorstatusitemx msi where monitorx.idx = 'M-TEST_1444-TEST_00_10560561260561463219352' Are you sure you sure you don't have any duplicated constraints by pulling information in from other tables that you don't need to? Removing some of those nested loops would make a significant impact to the results. -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc
Description: This is a digitally signed message part