Joel Fradkin wrote:
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

Reply via email to