Query running slower than same on Oracle

We are evaluating PostgreSQL for a typical data warehouse application. I
have 3 tables below that are part of a Star schema design. The query listed
below runs in 16 seconds on Oracle 9.2 and 3+ minutes on PostgreSQL 7.3.3
Here are the details.

I'm wondering what else can be done to tune this type of query. Is 3
minutes reasonable given the amount of data that is loaded into the 3
tables? Is there anyone else who has made comparisons between Oracle and
PostgreSQL?

----------------------------------------------------------------------------
------------------------------------------------------------------------
Oracle 9.2 is running on a windows/2000 server, 600MHz PIII, 512MB ram
Shared Pool 48MB
Buffer Cache 98MB
Large Pool 8MB
Java Pool 32MB
=========
Total SGA 186MB

----------------------------------------------------------------------------
------------------------------------------------------------------------
PostgreSQL is running on Redhat Linux 7.2, 733MHz PIII processor, 383MB ram.
shared_buffers = 12384 (96 MB)
sort_mem = 16384

----------------------------------------------------------------------------
------------------------------------------------------------------------

explain analyze
select fiscalyearquarter, description, sum(amount_quantity)
from time t, revenue r, statistic s
Where t.fiscalyear = 2002
and r.timekey = t.timekey
and r.statisticskey = s.statisticskey
group by fiscalyearquarter, description;

QUERY
PLAN
----------------------------------------------------------------------------
------------------------------------------------------------------------
Aggregate (cost=124685.74..127078.87 rows=23931 width=48) (actual
time=170682.53..189640.85 rows=8 loops=1)
-> Group (cost=124685.74..126480.59 rows=239313 width=48) (actual
time=169508.49..185478.90 rows=1082454 loops=1)
-> Sort (cost=124685.74..125284.02 rows=239313 width=48) (actual
time=169508.47..171853.03 rows=1082454 loops=1)
Sort Key: t.fiscalyearquarter, s.description
-> Hash Join (cost=6.46..94784.90 rows=239313 width=48)
(actual time=140.20..47685.46 rows=1082454 loops=1)
Hash Cond: ("outer".statisticskey =
"inner".statisticskey)
-> Hash Join (cost=5.43..90595.90 rows=239313
width=32) (actual time=139.96..39672.76 rows=1082454 loops=1)
Hash Cond: ("outer".timekey = "inner".timekey)
-> Seq Scan on revenue r (cost=0.00..68454.04
rows=3829004 width=17) (actual time=0.01..26336.95 rows=3829004 loops=1)
-> Hash (cost=5.40..5.40 rows=12 width=15)
(actual time=0.79..0.79 rows=0 loops=1)
-> Seq Scan on "time" t (cost=0.00..5.40
rows=12 width=15) (actual time=0.36..0.75 rows=12 loops=1)
Filter: (fiscalyear = 2002::numeric)
-> Hash (cost=1.02..1.02 rows=2 width=16) (actual
time=0.04..0.04 rows=0 loops=1)
-> Seq Scan on statistic s (cost=0.00..1.02
rows=2 width=16) (actual time=0.02..0.03 rows=2 loops=1)
Total runtime: 195409.79 msec

This gives you an idea of the size of each table in the query
----------------------------------------------------------------------------
------------------------------------------------------------------------

pubnet=# vacuum analyze verbose revenue;
INFO: --Relation dw.revenue--
INFO: Pages 30164: Changed 0, Empty 0; Tup 3829004: Vac 0, Keep 0, UnUsed
17.
Total CPU 1.87s/0.73u sec elapsed 9.97 sec.
INFO: Analyzing dw.revenue
VACUUM
pubnet=# vacuum analyze verbose statistic;
INFO: --Relation dw.statistic--
INFO: Pages 1: Changed 0, Empty 0; Tup 2: Vac 0, Keep 0, UnUsed 1.
Total CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO: Analyzing dw.statistic
VACUUM
pubnet=# vacuum analyze verbose time;
INFO: --Relation dw.time--
INFO: Pages 3: Changed 0, Empty 0; Tup 192: Vac 0, Keep 0, UnUsed 33.
Total CPU 0.00s/0.00u sec elapsed 0.02 sec.
INFO: Analyzing dw.time
VACUUM
pubnet=#

I tried to disable the use of hash join to see what might happen. This
causes the optimizer to use a merge join. The timings are worse.

Here is the plan for that

QUERY PLAN

----------------------------------------------------------------------------
----------------------------------------------------------------------------
--------
Aggregate (cost=665570.44..667963.57 rows=23931 width=48) (actual
time=362121.97..381081.18 rows=8 loops=1)
-> Group (cost=665570.44..667365.29 rows=239313 width=48) (actual
time=360948.51..376904.14 rows=1082454 loops=1)
-> Sort (cost=665570.44..666168.72 rows=239313 width=48) (actual
time=360948.48..363285.85 rows=1082454 loops=1)
Sort Key: t.fiscalyearquarter, s.description
-> Merge Join (cost=631481.61..635669.60 rows=239313
width=48) (actual time=263257.77..276625.27 rows=1082454 loops=1)
Merge Cond: ("outer".statisticskey =
"inner".statisticskey)
-> Sort (cost=631480.58..632078.86 rows=239313
width=32) (actual time=260561.38..264151.04 rows=1082454 loops=1)
Sort Key: r.statisticskey
-> Merge Join (cost=587963.25..610099.74
rows=239313 width=32) (actual time=217380.88..231958.36 rows=1082454
loops=1)
Merge Cond: ("outer".timekey =
"inner".timekey)
-> Sort (cost=5.62..5.65 rows=12
width=15) (actual time=14.90..14.92 rows=12 loops=1)
Sort Key: t.timekey
-> Seq Scan on "time" t
(cost=0.00..5.40 rows=12 width=15) (actual time=13.47..14.83 rows=12
loops=1)
Filter: (fiscalyear =
2002::numeric)
-> Sort (cost=587957.63..597530.14
rows=3829004 width=17) (actual time=214776.92..224634.94 rows=1455997
loops=1)
Sort Key: r.timekey
-> Seq Scan on revenue r
(cost=0.00..68454.04 rows=3829004 width=17) (actual time=1.33..31014.95
rows=3829004 loops=1)
-> Sort (cost=1.03..1.03 rows=2 width=16) (actual
time=2696.35..3765.93 rows=541228 loops=1)
Sort Key: s.statisticskey
-> Seq Scan on statistic s (cost=0.00..1.02
rows=2 width=16) (actual time=19.50..19.52 rows=2 loops=1)
Total runtime: 385939.85 msec

The Query plan in Oracle looks like this...
----------------------------------------------------------------------------
----------------------------------------------------------------------------
--------
SORT GROUP BY
HASH JOIN
MERGE JOIN CARTESIAN
TABLE ACCESS FULL DBA_ADMIN
STATISTIC
BUFFER SORT
TABLE ACCESS FULL DBA_ADMIN
TIME
TABLE ACCESS FULL DBA_ADMIN
REVENUE