Hola Alvaro,
Las fechas están correctas, la versión postgresql 12 veo que usa mucho las
búsquedas en el heap antes de usar los índices, tal vez un problema de
configuración.
Otro ejemplo es la siguiente consulta que tarda una eternidad, y se supone
que no hay registro que coincida en el where
explain select max(id) from invoices where num_ruc='20524953189';
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------
Result (cost=474.18..474.19 rows=1 width=8)
InitPlan 1 (returns $0)
-> Limit (cost=0.57..474.18 rows=1 width=8)
-> Index Scan Backward using invoices_pkey on ose_ticket
(cost=0.57..8389569.35 rows=17714 width=8)
Index Cond: (id IS NOT NULL)
Filter: ((num_ruc)::text = '20524953189'::text)
(6 rows)
El campo num_ruc está indexado pero el motor decide que usa el índice del
id y busca con filter el num_ruc
*Ahora si la consulta uso CTE la respuesta es instantánea*
explain (analyze,buffers) with T1 as (select id from invoices where
num_ruc='20524953189') select max(id) from T1;
QUERY
PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=67413.58..67413.59 rows=1 width=8) (actual
time=0.019..0.019 rows=1 loops=1)
Buffers: shared hit=4
-> Bitmap Heap Scan on invoices (cost=701.85..67369.30 rows=17714
width=8) (actual time=0.016..0.017 rows=0 loops=1)
Recheck Cond: ((num_ruc)::text = '20524953189'::text)
Buffers: shared hit=4
-> Bitmap Index Scan on idx7tfrebfdhytkiavp6fobro3ct
(cost=0.00..697.42 rows=17714 width=0) (actual time=0.015..0.016 rows=0
loops=1)
Index Cond: ((num_ruc)::text = '20524953189'::text)
Buffers: shared hit=4
Planning Time: 0.076 ms
Execution Time: 0.039 ms
(10 rows)
Estás cosas no pasaban con la versión anterior "9.6", seguiré probando a
ver si encuentro el problema o migro a la versión 10 o 11.
Saludos.
El mié., 14 oct. 2020 a las 16:19, Alvaro Herrera (<alvhe...@alvh.no-ip.org>)
escribió:
> Jairo Graterón escribió:
>
> > Ahora tenemos una consulta lenta que está afectando el rendimiento en el
> > sistema
>
> y cual era la consulta?
>
> Lo que me parece mas sospechoso es que los literales de la columna
> fecha_de_emision son timestamp without time zone. Quizas estas pasando
> el tipo de dato equivocado en esa columna y por eso no usa ningun
> indice. Es JDBC esto? o sentencias preparadas?
>
> Saludos
>
>
>
