crosstab speed

ok, I have an application that I am trying to speed up. Its a reporting application that makes heavy use of the crosstab function.

Here is some of the setup / configuration details:
Postgres 8.3.3
RedHat Enterprise 5.2 (2.6.18 kernel)
sun x4600, 8 dual core opteron 8218 processors,  32BG, StorageTek SAN
6 15k FC disks raid 10 for data,
2 15k FC disks raid 1 for xlog,
2 10k SAS disks raid 1 for OS
The table that I am querying has just under 600k records, 55 columns, 30 indexes
The table is not static, there are several hundred inserts a day into it.
This is not the only application that uses postgres on this server. There are several other transactional apps as well

here is an example query
  select "COL_HEAD"[1] as site, "COL_HEAD"[2] as product_line_description, "COL_HEAD"[3] as report_sls, "COL_HEAD"[4] as fy_period, "2006"  , "2007"  , "2008"  , "2009"   from public.crosstab('select  ARRAY[site::text,product_line_description::text,report_sls::text,fy_period::text] as COL_HEADER, fy_year, sum(invoice_value) from order_data_tbl  where  fy_year is not null  group by site::text,product_line_description::text,report_sls::text,fy_period::text, fy_year order by site::text,product_line_description::text,report_sls::text,fy_period::text', 'select fy_year from order_data_tbl where   fy_year is not null   group by fy_year  order by fy_year') as order_data_tbl("COL_HEAD" text[], "2006"  numeric(20,2) , "2007"  numeric(20,2) , "2008"  numeric(20,2) , "2009"  numeric(20,2) )

The crostab function is taking between 5 and 15 seconds to return. While the query is running one of the cores will be close to 100%, but watching iostat makes be believe that the entire table is cached and none of it is being read from disk. Depending on what report is being run the indexes may or may not be of any assistance. In the above query the planner does not use an index. Depending on what the user is looking for some indexes will be used because there is more specified in the where clause, at which point the query time can be under two seconds. The problem is that most reports that get generated with this application don't have a where clause. Are there any changes that can make to my config to speed up these huge aggregating queries?

Here is my postgresql.conf

max_connections = 1500   
shared_buffers = 8GB       
work_mem = 2GB           
maintenance_work_mem = 8GB   
max_fsm_pages = 2048000           
wal_buffers = 1024kB           
checkpoint_segments = 256
checkpoint_timeout = 10min       
effective_cache_size = 20GB
default_statistics_target = 100       
log_destination = 'stderr'       
logging_collector = on       
log_directory = 'pg_log'       
log_truncate_on_rotation = on
log_rotation_age = 1d       
log_rotation_size = 1GB
log_error_verbosity = default
autovacuum = on
autovacuum_max_workers = 9
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'   
lc_numeric = 'en_US.UTF-8'   
lc_time = 'en_US.UTF-8'       
default_text_search_config = 'pg_catalog.english'
synchronize_seqscans = on
log_min_duration_statement = 250


-Jeremiah Elliott