: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Very slow postgreSQL 9.3.4 query
Hi,
Two things:
- Make sure you are creating a GIST index on your geometry column in postgis.
- Try using st_intersects rather than &&. I've noticed that && isn't using
indices co
em = 16MB
> maintenance_work_mem = 1GB
> seq_page_cost = 1.0
> random_page_cost = 2.0
> cpu_tuple_cost = 0.03
> effective_cache_size = 48GB
>
>
> From: Graeme B. Bell [g...@skogoglandskap.no]
> Sent: Friday, September 26, 2014 9:55 AM
> To:
: [PERFORM] Very slow postgreSQL 9.3.4 query
2014-09-26 23:07 GMT+03:00 Burgess, Freddie
mailto:fburg...@radiantblue.com>>:
I have a cron job that updates the statistics on the "doti_sensor_report" table
on the first Saturday of every month. Do you think I should re-generate these
ll generate new stat's over the weekend, and then execute a new plan
thanks
From: Victor Yegorov [vyego...@gmail.com]
Sent: Friday, September 26, 2014 3:15 PM
To: Burgess, Freddie
Subject: Re: [PERFORM] Very slow postgreSQL 9.3.4 query
2014-09-26 19:17 GMT+03
...@skogoglandskap.no]
Sent: Friday, September 26, 2014 9:55 AM
To: Burgess, Freddie
Cc: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Very slow postgreSQL 9.3.4 query
A good way to start would be to introduce the query - describe what it is meant
to do, give some performance data (your
A good way to start would be to introduce the query - describe what it is meant
to do, give some performance data (your measurements of time taken, amount of
data being processed, hardware used etc).
Graeme.
On 26 Sep 2014, at 15:04, Burgess, Freddie wrote:
> Help, please can anyone offer s
Help, please can anyone offer suggestions on how to speed this query up.
thanks
dotidb=# select count(*) from doti_sensor_report_y2014m09;
count
--
184,888,345
(1 row)
dotidb=# \d+ doti_sensor_report_y2014m09 <-- Partition table of parent table
public.doti_sensor_report
