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
On Thu, Jan 7, 2010 at 1:43 PM, Brian Cox brian@ca.com 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
On Mon, Jan 4, 2010 at 5:24 PM, Brian Cox brian@ca.com wrote:
On 01/04/2010 04:53 PM, Robert Haas [robertmh...@gmail.com] wrote:
PREPARE foo AS the query, with the $x entries still in there
EXPLAIN EXECUTE foo(the values);
Thanks for the response. Results below. Brian
cemdb= prepare
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
On Tue, Jan 5, 2010 at 4:33 PM, Brian Cox brian@ca.com 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
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
On Mon, Jan 4, 2010 at 2:41 PM, Brian Cox brian@ca.com 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
On 01/04/2010 04:53 PM, Robert Haas [robertmh...@gmail.com] wrote:
PREPARE foo AS the query, with the $x entries still in there
EXPLAIN EXECUTE foo(the values);
Thanks for the response. Results below. Brian
cemdb= prepare foo as select count(distinct b.ts_id) from