Re: Execution plan does not use index

> Curious, how accurate is that row count of 1.2 million records for 3 days? Not to bad actually select count(mv_inner.*) from measurement_value AS mv_inner where mv_inner.timestamp > '2020-11-06'::timestamp - interval '1 day' and mv_inner.timestamp < '2020-11-07'::timestamp + interval '1 day'

Re: Execution plan does not use index

On Tue, Nov 10, 2020, 3:24 PM Peter Coppens wrote: > Index is not used for the subquery > > explain > select mv_inner.* > from measurement_value AS mv_inner > where mv_inner.timestamp > '2020-11-06'::timestamp - interval '1 day' > and mv_inner.timestamp < '2020-11-07'::timestamp + interval '1

Re: Execution plan does not use index

> > Curious, what is seq_page_cost and random_page_cost? show seq_page_cost ->1 show random_page_cost ->4 > Any idea of your cache hits for indexes? No, I am afraid not. It’s been a long time since I went that deep in the RDBMS behaviour (must have been Oracle 7.something :) ) > If they a

Re: Execution plan does not use index

On Tue, Nov 10, 2020 at 1:25 AM Peter Coppens wrote: > Triggered by Michael mentioning subqueries I ended up trying > > explain > select d.short_id,mv.timestamp ,mv.I64_01 > from device d, device_configuration dc, measurement_value mv > where mv.device_id=d.short_id and dc.device_id = d.id

psycopg3 and adaptation choices

Hello, I am developing psycopg3 , a major release of the psycopg2 PostgreSQL driver for Python. This release finally uses the advanced query protocol and server-side parameters binding, so adaptation of Python values to PostgreSQL data types has, at times, a diff

Re: Different result behavior when using ANY(ARRAY(SELECT)) and IN (SELECT)

Thanks for the suggestion, I've tried to edit the query and added an order by in the OVER statement but i'm still obtaining two results, but now of course those results are sequential, the edited beginning of the query is: SELECT * FROM ( SELECT _id, ROW_NUMBE

Re: Execution plan does not use index

Triggered by Michael mentioning subqueries I ended up trying explain select d.short_id,mv.timestamp ,mv.I64_01 from device d, device_configuration dc, measurement_value mv where mv.device_id=d.short_id and dc.device_id = d.id and dc.latest=true and mv.timestamp > '2020-11-06'::times

Re: Execution plan does not use index

Pavel Tx for the tip. But given that if the I64_01 column is removed from the select list, the index is used I guess the cast is not likely to be the cause. Like so explain select d.short_id,mv.timestamp --,mv.I64_01 from device d, device_configuration dc, measurement_value mv, pg_timezo