Re: query looping?

also compare:

[4258-cemdb-admin-2010-01-05 13:11:42.913 PST]LOG:  duration: 6401.314 
ms  statement: execute foo('2010-01-03 00:00','2010-01-03 
08:00','2009-12-28 00:00','2010-01-04 00:00');
[4258-cemdb-admin-2010-01-05 13:11:42.913 PST]DETAIL:  prepare: prepare 
foo as select count(distinct b.ts_id) from 
ts_stats_transetgroup_user_weekly b, ts_stats_transet_user_interval c, 
ts_transetgroup_transets_map m where b.ts_transet_group_id = 
m.ts_transet_group_id and m.ts_transet_incarnation_id = 
c.ts_transet_incarnation_id and c.ts_user_incarnation_id = 
b.ts_user_incarnation_id and c.ts_interval_start_time >= $1 and 
c.ts_interval_start_time < $2 and b.ts_interval_start_time >= $3 and 
b.ts_interval_start_time < $4;

still the original query is ~20,000 times slower. Here's the explain foo 
output for the execute above:

cemdb=> explain execute foo('2010-01-03 00:00','2010-01-03 
08:00','2009-12-28 00:00','2010-01-04 00:00'); 
                                                        QUERY PLAN 
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  Aggregate  (cost=347318.10..347318.11 rows=1 width=8)
    ->  Hash Join  (cost=3836.14..347317.41 rows=549 width=8)
          Hash Cond: ((b.ts_transet_group_id = m.ts_transet_group_id) 
AND (c.ts_transet_incarnation_id = m.ts_transet_incarnation_id))
          ->  Hash Join  (cost=3834.30..347302.98 rows=2628 width=24)
                Hash Cond: (c.ts_user_incarnation_id = 
b.ts_user_incarnation_id)
                ->  Bitmap Heap Scan on ts_stats_transet_user_interval c 
  (cost=2199.30..343132.02 rows=103500 width=16)
                      Recheck Cond: ((ts_interval_start_time >= $1) AND 
(ts_interval_start_time < $2))
                      ->  Bitmap Index Scan on 
ts_stats_transet_user_interval_starttime  (cost=0.00..2186.36 
rows=103500 width=0)
                            Index Cond: ((ts_interval_start_time >= $1) 
AND (ts_interval_start_time < $2))
                ->  Hash  (cost=1627.99..1627.99 rows=1122 width=24)
                      ->  Index Scan using 
ts_stats_transetgroup_user_weekly_starttimeindex on 
ts_stats_transetgroup_user_weekly b  (cost=0.00..1627.99 rows=1122 width=24)
                            Index Cond: ((ts_interval_start_time >= $3) 
AND (ts_interval_start_time < $4))
          ->  Hash  (cost=1.33..1.33 rows=67 width=16)
                ->  Seq Scan on ts_transetgroup_transets_map m 
(cost=0.00..1.33 rows=67 width=16)
(14 rows)

comparing this to the 1st explain foo output shows some minor 
differences in row estimates -- but nothing, I assume, that could 
explain the huge time difference. Of course, the 1st plan may not (and 
probably? wasn't) the plan that was used to take 124M ms.

Any thoughts on how to avoid this?

Thanks,
Brian