On Thu, Jan 7, 2010 at 1:43 PM, Brian Cox wrote:
> On 01/05/2010 08:34 PM, Robert Haas [robertmh...@gmail.com] wrote:
>>
>> - If you have other queries where this index helps (even though it is
>> hurting this one), then you're going to have to find a way to execute
>> the query without using boun
On 01/05/2010 08:34 PM, Robert Haas [robertmh...@gmail.com] wrote:
- If you have other queries where this index helps (even though it is
hurting this one), then you're going to have to find a way to execute
the query without using bound parameters - i.e. with the actual values
in there instead of
On Tue, Jan 5, 2010 at 4:33 PM, Brian Cox wrote:
> 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 t
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.t
SELECT SUM(1) FROM ts_stats_transetgroup_user_weekly b WHERE
ts_interval_start_time > [value] AND ts_interval_start_time < [value];
...and similarly for the bitmap index scan.
cemdb=> SELECT SUM(1) FROM ts_stats_transetgroup_user_weekly b WHERE
ts_interval_start_time >= '2009-12-28' AND ts_inter
On Mon, Jan 4, 2010 at 5:24 PM, Brian Cox wrote:
> On 01/04/2010 04:53 PM, Robert Haas [robertmh...@gmail.com] wrote:
>>
>> PREPARE foo AS
>> EXPLAIN EXECUTE foo();
>
> Thanks for the response. Results below. Brian
>
> cemdb=> prepare foo as select count(distinct b.ts_id) from
> ts_stats_transetg
On 01/04/2010 04:53 PM, Robert Haas [robertmh...@gmail.com] wrote:
PREPARE foo AS
EXPLAIN EXECUTE foo();
Thanks for the response. Results below. Brian
cemdb=> prepare foo as select count(distinct b.ts_id) from
ts_stats_transetgroup_user_weekly b, ts_stats_transet_user_interval c,
ts_transet
On Mon, Jan 4, 2010 at 2:41 PM, Brian Cox wrote:
> The query shown below [select count(distinct...] seems to be looping
> (99-101% CPU as shown by top for 11+ hours). This using postgres 8.3.5 on a
> dual quad core machine (Intel(R) Xeon(R) CPU X5460 @ 3.16GHz) with 32G RAM.
> Can I provide any ot
The query shown below [select count(distinct...] seems to be looping
(99-101% CPU as shown by top for 11+ hours). This using postgres 8.3.5
on a dual quad core machine (Intel(R) Xeon(R) CPU X5460 @ 3.16GHz) with
32G RAM. Can I provide any other info to help investigate this issue? Or
any though
