Slow query on partitioned table.

2018-03-27 Thread Glenn Pierce 
Hi I am having terrible trouble with a simple partitioned table.
Select queries are very slow.

Ie

SELECT ts::timestamptz, s1.sensor_id, s1.value
  FROM sensor_values s1
   WHERE s1.sensor_id =
ANY(ARRAY[596304,597992,610978,597998])
 AND s1.ts >= '2000-01-01
00:01:01'::timestamptz AND
 s1.ts < '2018-03-20
00:01:01'::timestamptz

Takes over five minutes.


Postgres version is PostgreSQL 9.5.9 on x86_64-pc-linux-gnu, compiled
by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11), 64-bit
shared_buffers = 3000MB
work_mem = 50MB
maintenance_work_mem = 64MB
wal_writer_delay = 1ms
#effective_cache_size = 4GB  I guess this is the default

My amount of memory is 15G


The table gets constant inserts (thousands a minute)
The table has something like 7 rows.

So the table is defined as


\d+ sensor_values;
   Table "public.sensor_values"
  Column   |   Type   | Modifiers
| Storage | Stats target | Description
---+--++-+--+-
 ts| timestamp with time zone | not null
| plain   |  |
 value | double precision | not null default 'NaN'::real
| plain   |  |
 sensor_id | integer  | not null
| plain   |  |
 status| tridium_status   | not null default
'unknown'::tridium_status | plain   |  |
Indexes:
"sensor_values_sensor_id_timestamp_index" UNIQUE, btree (sensor_id, ts)
Foreign-key constraints:
"sensor_values_sensor_id_fkey" FOREIGN KEY (sensor_id) REFERENCES
sensors(id)
Triggers:
a_statistics_trigger BEFORE INSERT OR DELETE ON sensor_values FOR
EACH ROW EXECUTE PROCEDURE stat_info()
sensor_values_trigger_timestamp_sensor_insert_sensor_values BEFORE
INSERT ON sensor_values FOR EACH ROW EXECUTE PROCEDURE
sensor_values_timestamp_sensor_func_insert_trigger()
Child tables: sensor_values_2007q1,
  sensor_values_2007q2,
  sensor_values_2007q3,
  sensor_values_2007q4,
  sensor_values_2008q1,
  sensor_values_2008q2,
  sensor_values_2008q3,
  sensor_values_2008q4,
  sensor_values_2009q1,
  sensor_values_2009q2,
  sensor_values_2009q3,
  sensor_values_2009q4,
  sensor_values_2010q1,
  sensor_values_2010q2,
  sensor_values_2010q3,
  sensor_values_2010q4,
  sensor_values_2011q1,
  sensor_values_2011q2,
  sensor_values_2011q3,
  sensor_values_2011q4,
  sensor_values_2012q1,
  sensor_values_2012q2,
  sensor_values_2012q3,
  sensor_values_2012q4,
  sensor_values_2013q1,
  sensor_values_2013q2,
  sensor_values_2013q3,
  sensor_values_2013q4,
  sensor_values_2014q1,
  sensor_values_2014q2,
  sensor_values_2014q3,
  sensor_values_2014q4,
  sensor_values_2015q1,
  sensor_values_2015q2,
  sensor_values_2015q3,
  sensor_values_2015q4,
  sensor_values_2016q1,
  sensor_values_2016q2,
  sensor_values_2016q3,
  sensor_values_2016q4,
  sensor_values_2017q1,
  sensor_values_2017q2,
  sensor_values_2017q3,
  sensor_values_2017q4,
  sensor_values_2018q1,
  sensor_values_2018q2,
  sensor_values_2018q3,
  sensor_values_2018q4,
  sensor_values_2019q1,
  sensor_values_2019q2,
  sensor_values_2019q3,
  sensor_values_2019q4,
  sensor_values_2020q1,
  sensor_values_2020q2,
  sensor_values_2020q3,
  sensor_values_2020q4



The child tables are all like

  Column   |   Type   | Modifiers
| Storage | Stats target | Description
---+--++-+--+-
 ts| timestamp with time zone | not null
| plain   |  |
 value | double precision | not null default 'NaN'::real
| plain   |  |
 sensor_id | integer  | not null
| plain   |  |
 status| tridium_status   | not null default
'unknown'::tridium_status | plain   |  |
Indexes:
"sensor_values_2018q1_sensor_id_timestamp_index" UNIQUE, btree
(sensor_id, ts)
Check constraints:
"sensor_values_2018q1_timestamp_check" CHEC

Re: Slow query on partitioned table.

2018-03-27 Thread Justin Pryzby 
On Tue, Mar 27, 2018 at 03:14:30PM +0100, Glenn Pierce wrote:
> Hi I am having terrible trouble with a simple partitioned table.
> Select queries are very slow.

> The child tables are all like
> Check constraints:
> "sensor_values_2018q1_timestamp_check" CHECK (ts >= '2018-01-01
> 00:00:00+00'::timestamp with time zone AND ts < '2018-04-01
> 01:00:00+01'::timestamp with time zone)

> EXPLAIN (ANALYZE, BUFFERS)  SELECT ts::timestamptz, s1.sensor_id, s1.value
>   FROM sensor_values s1
>WHERE s1.sensor_id =
> ANY(ARRAY[596304,597992,610978,597998])
>  AND s1.ts >= '2000-01-01
> 00:01:01'::timestamptz AND
>  s1.ts < '2018-03-20
> 00:01:01'::timestamptz

> Shows the following output
> https://explain.depesz.com/s/c8HU

It's scanning all partitions, so apparently constraint_exclusion isn't working.

Is it because the CHECK has ts with different timezones +00 and +01 ??

Also, it looks funny to use 00:01:01 as the beginning of the day (although I
think it's true that an HR department would understand that better..).

Justin

Re: Slow query on partitioned table.

2018-03-27 Thread Justin Pryzby 
Re-added -performance.

On Tue, Mar 27, 2018 at 05:13:25PM +0100, Glenn Pierce wrote:
> Damn as I was playing with the indexes I must have deleted the constraints :(
> Question if I have a constraint like
> 
> ALTER TABLE sensor_values_2007q1
>   ADD CONSTRAINT sensor_values_2007q1_sensor_id_timestamp_constraint
> UNIQUE (sensor_id, ts);
> 
> will that be used like an index  or do I need to add a separate index ?

Yes:

https://www.postgresql.org/docs/current/static/ddl-constraints.html
|Adding a unique constraint will automatically create a unique B-tree index on
the column or group of columns listed in the constraint

https://www.postgresql.org/docs/current/static/indexes-unique.html
|PostgreSQL automatically creates a unique index when a unique constraint or
|primary key is defined for a table. The index ... is the mechanism that
|enforces the constraint.

Justin