Explain Analyze returns faster than psql or JDBC calls.

Hi there

We are runing Postgres 8.3.7 on a
We have a problem with Explain Analyze that we haven't seen before.

we run an Explain Analyze on a query.

Nested Loop (cost=1256.32..2097.31 rows=198 width=1120) (actual
time=12.958..20.846 rows=494 loops=1)
-> HashAggregate (cost=1256.32..1256.92 rows=198 width=4) (actual
time=12.936..13.720 rows=494 loops=1)
-> Limit (cost=1255.53..1255.63 rows=198 width=20) (actual
time=9.841..11.901 rows=500 loops=1)
-> Sort (cost=1255.53..1255.63 rows=198 width=20) (actual
time=9.838..10.588 rows=500 loops=1)
Sort Key: ((abs((ri_metadata.latitude -
44.0247062::double precision)) + abs((ri_metadata.longitude -
(-88.5426136)::double precision))))
Sort Method: quicksort Memory: 52kB
-> Bitmap Heap Scan on ri_metadata
(cost=385.54..1254.02 rows=198 width=20) (actual time=4.638..8.558 rows=595
loops=1)
Recheck Cond: ((latitude > 43.6687062::double
precision) AND (latitude < 44.3807062::double precision) AND (longitude >
(-88.8986136)::double precision) AND (longitude < (-88.1866136)::double
precision))
Filter: (category_id = ANY
('{3,274,4,1,2,275,7,278,8,277,5,280,6,279,11,9,10,15,285,16,14,19,18,17,24,23,21,266,25,32,31,30,29,40,34,48,41,44,313,54,53,55,50,52,62,61,63,302,58,57,59,71,341,69,67,338,68,337,65,66,339,79,352,77,78,74,85,83,324,81,334,335,336,372,376,373,374,363,122,368,127,128,356,355,360,359,118,358,357,140,139,138,137,143,142,141,132,130,129,135,134,191,185,186,187,188,183,202,200,193,219}'::integer[]))
-> Bitmap Index Scan on
ri_metadata_latitude_longitude_category_id_idx (cost=0.00..385.53 rows=462
width=0) (actual time=4.533..4.533 rows=1316 loops=1)
Index Cond: ((latitude > 43.6687062::double
precision) AND (latitude < 44.3807062::double precision) AND (longitude >
(-88.8986136)::double precision) AND (longitude < (-88.1866136)::double
precision))
-> Index Scan using ri_result_result_id_idx on ri_result
(cost=0.00..4.24 rows=1 width=1120) (actual time=0.006..0.008 rows=1
loops=494)
Index Cond: (ri_result.result_id = ri_metadata.result_id)
Total runtime: 21.658 ms
(14 rows)

It takes only *21* ms. Then we run the same query on psql (on localhost)
with timing on

select * from ri_result where result_id in
(select result_id from ri_metadata
WHERE category_id IN
(3,274,4,1,2,275,7,278,8,277,5,280,6,279,11,9,10,15,285,16,14,19,18,17,24,23,21,266,25,32,31,30,29,40,34,48,41,44,313,54,53
,55,50,52,62,61,63,302,58,57,59,71,341,69,67,338,68,337,65,66,339,79,352,77,78,74,85,83,324,81,334,335,336,372,376,373,374,363,122,368,127,
128,356,355,360,359,118,358,357,140,139,138,137,143,142,141,132,130,129,135,134,191,185,186,187,188,183,202,200,193,219)
AND latitude >43.668706199999995 AND latitude <44.3807062 AND
longitude>-88.89861359999999 AND longitude<-88.1866136
order by abs(latitude - 44.0247062)+abs(longitude - -88.5426136) limit
500)
;
Time: 2611.491 ms

The longer runtime from psql console is corroborated when we do same
queries via JDBC
How can explain-analyze return significantly much faster than other means?
(I understand that some data is returned from the query to either client end
on psql or to a resultset in jdbc as opposed to a small chunk of data in
the form of a plan but still..,)
By the way, I run the explain analyze first and then run the query to avoid
any caching.

Our system : Ubuntu Ubuntu 8.04.3 64 bit, 8GB RAM ,2 GHz single core,
running a vm on an esx server. the database is read-only.

ri_metadata has 1473864 rows, 200MB,
Table "public.ri_metadata"
Column | Type |
Modifiers
----------------+-----------------------------+----------------------------------------------------------------------
ri_metadata_id | integer | not null default
nextval('ri_metadata_ri_metadata_id_seq'::regclass)
result_id | integer | not null
start_time | timestamp without time zone | not null
end_time | timestamp without time zone | not null
category_id | integer | not null
category_name | text | not null
location_id | integer |
longitude | double precision |
latitude | double precision |
city | text |
state | text |
zip | text |
street_address | text |
Indexes:
"ri_metadata_pkey" PRIMARY KEY, btree (ri_metadata_id)
"ri_metadata_category_id_idx" btree (category_id)
"ri_metadata_category_id_state" btree (category_id, state)
"ri_metadata_end_time_idx" btree (end_time)
"ri_metadata_latitude_idx" btree (latitude)
"ri_metadata_latitude_longitude_category_id_idx" btree (latitude,
longitude, category_id)
"ri_metadata_location_id_idx" btree (location_id)
"ri_metadata_longitude_idx" btree (longitude)
"ri_metadata_result_id_idx" btree (result_id)
"ri_metadata_start_time_idx" btree (start_time)
"ri_metadata_state_idx" btree (state)

ri_result has 1323061 rows, 3.3GB total size

Table "public.ri_result"
Column | Type | Modifiers
--------------+------------------+------------------------------------------------------------------
ri_result_id | integer | not null default
nextval('ri_result_ri_result_id_seq'::regclass)
result_id | integer | not null
facets | bytea | not null
props | bytea | not null
random | double precision |
Indexes:
"ri_result_pkey" PRIMARY KEY, btree (ri_result_id)
"ri_result_random_idx" btree (random)
"ri_result_result_id_idx" btree (result_id)