I must be missing something important, because I am just not seeing why this query is slower on a 4 processor 8 gig machine running redhat AS4.
Well, the 4 processors aren't going to help with a single query. However, assuming the configurations for both machines are comparable, you shouldn't be seeing a doubling in query-time.
I have, however, spotted something very strange towards the bottom of each explain:
Machine 1 my desktop:
" -> Merge Right Join (cost=0.00..52366.50 rows=190710 width=75)
(actual time=16.000..1973.000 rows=177041 loops=1)"
" Merge Cond: ((("outer".clientnum)::text =
("inner".clientnum)::text) AND ("outer".id = "inner".jobtitleid))"
Test Linux machine:
" -> Merge Right Join (cost=24825.80..27512.71 rows=176015
width=75) (actual time=8743.848..9750.775 rows=177041 loops=1)"
" Merge Cond: ((("outer".clientnum)::text =
"inner"."?column10?") AND ("outer".id = "inner".jobtitleid))"
In the first, we match outer.clientnum to inner.clientnum, in the second it's "?column10?" - are you sure the query was identical in each case. I'm guessing the unidentified column in query 2 is the reason for the sort a couple of lines below it, which seems to take up a large chunk of time.
-- Richard Huxton Archonet Ltd
---------------------------(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
