Hola Hellmuth, puedes deshabilitar el seq_scan y ver que retorna el
explain analyze para es consulta
set enable_seqscan = off;
Saludos
El 29-11-19 a las 12:09, Hellmuth Vargas escribió:
Hola lista
tengo una tabla
CREATE TABLE oportunidadcitas
(
id bigint NOT NULL,
fechacreacion timestamp without time zone,
fechamodificacion timestamp without time zone,
centrocodigo character varying(255),
especialidadcodigo character varying(255),
medicocodigo character varying(255),
CONSTRAINT oportunidadcitas_pkey PRIMARY KEY (id)
)
con el siguiente indice (entre otros)
CREATE INDEX idx_ oportunidadcitas_desc
ON oportunidadcitas
USING btree
( centrocodigo COLLATE pg_catalog."default", id DESC);
donde suponía que podrá apoyar una consulta recurrente que hacen:
select centrocodigo,max( id ) as ultimo
from oportunidadcitas
group by 1
Pero el motor siempre prefiere hacer el sequence scan:
HashAggregate (cost=7307.83..7307.85 rows=5 width=21) (actual
time=122.891..122.893 rows=5 loops=1)
Group Key: centrocodigo
-> Seq Scan on oportunidadcitas (cost=0.00..7159.26 rows=148566
width=21) (actual time=0.011..43.675 rows=148624 loops=1)
Planning time: 0.101 ms
Execution time: 122.928 ms
La pregunta es: porque si tiene un indice por ambos campos e incluso
esta ordenado por id desc porque no lo emplea para sacar el máximo???
( ni el mínimo) como si lo emplea si solo se hace el max por id:
select max( id )
from subred.baseoportunidadcitabot sub
Result (cost=0.14..0.15 rows=1 width=0)
InitPlan 1 (returns $0)
-> Limit (cost=0.08..0.14 rows=1 width=8)
-> Index Only Scan Backward using idx_
oportunidadcitas_desc on oportunidadcitas (cost=0.08..9988.24
rows=165172 width=8)
Index Cond: (id IS NOT NULL)
Postdata: la idea es sacarlo directamente porque varias
publicaciones sugieren emplear trigger o vistas materializadas para
almacenar el dato.
de antemano Gracias!!!
--
Cordialmente,
Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
