Thank you guys for spotting the problem immediately.
The reason for such autovacuum thresholds is that these tables are designed
for very high rate of inserts and I have a specific routine to analyze them
in a more controlled way. Infact the stats target of some of the fields is
also high. However
On Fri, Oct 14, 2011 at 2:35 AM, Svetlin Manavski
wrote:
> Thank you guys for spotting the problem immediately.
> The reason for such autovacuum thresholds is that these tables are designed
> for very high rate of inserts and I have a specific routine to analyze them
> in a more controlled way. In
It seems like your row estimate are way off, with the planner
expecting 1 and getting 3000 or so. Have you tried cranking up
default stats target to say 1000, running analyze and seeing what
happens?
If that doesn't do it, try temporarily turning off nested loops:
set enable_nestloop = off;
expl
Svetlin Manavski writes:
> I am running 9.03 with the settings listed below. I have a prohibitively
> slow query in an application which has an overall good performance:
It's slow because the planner is choosing a nestloop join on the
strength of its estimate that there's only a half dozen rows t
Hi all,
I am running 9.03 with the settings listed below. I have a prohibitively
slow query in an application which has an overall good performance:
select
cast (SD.detectorid as numeric),
CAST( ( (SD.createdtime - 0 )/ 18::bigint ) AS numeric) as
timegroup,
sum(datafromsou
