Hola Anthony NO, eso es claro que sale mas costoso.. pero la pregunta va a que si tengo un indice por centro y id (este ordenado desc) no debería poder sacar el máximo por cada centro empleando exclusivamente el indice?
El vie., 29 de nov. de 2019 a la(s) 10:54, Anthony Sotolongo ( asotolo...@gmail.com) escribió: > Creo que tu respuesta está ahí, para las estadísticas que tiene esa tabla > es más efectivo hacer un seq scan que usar el indice > > Saludos > > El vie., 29 de nov. de 2019 12:45 p. m., Hellmuth Vargas <hiv...@gmail.com> > escribió: > >> >> Hola Anthony! >> >> Asi me fue: >> >> set enable_seqscan = off; >> >> >> HashAggregate (cost=21803.61..21803.63 rows=5 width=21) (actual >> time=708.525..708.525 rows=5 loops=1) >> Group Key: centrocodigo >> -> Bitmap Heap Scan on oportunidadcitas (cost=2769.30..21416.55 >> rows=387062 width=21) (actual time=143.449..538.962 rows=387034 loops=1) >> Heap Blocks: exact=17099 >> -> Bitmap Index Scan on >> idx_oportunidadcitas_desc (cost=0.00..2749.95 rows=387062 width=0) >> (actual time=140.236..140.236 rows=387300 loops=1) >> Planning time: 0.118 ms >> Execution time: 708.580 ms >> >> >> ---- >> set enable_seqscan = on; >> >> HashAggregate (cost=19204.02..19204.04 rows=5 width=21) (actual >> time=241.997..241.998 rows=5 loops=1) >> Group Key: centrocodigo >> -> Seq Scan on oportunidadcitas (cost=0.00..18813.62 rows=390405 >> width=21) (actual time=0.004..73.800 rows=390405 loops=1) >> Planning time: 0.089 ms >> Execution time: 242.030 ms >> >> >> El vie., 29 de nov. de 2019 a la(s) 10:39, Anthony Sotolongo ( >> asotolo...@gmail.com) escribió: >> >>> 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 >>> >>> >> >> -- >> Cordialmente, >> >> Ing. Hellmuth I. Vargas S. >> Esp. Telemática y Negocios por Internet >> Oracle Database 10g Administrator Certified Associate >> EnterpriseDB Certified PostgreSQL 9.3 Associate >> >> -- Cordialmente, Ing. Hellmuth I. Vargas S. Esp. Telemática y Negocios por Internet Oracle Database 10g Administrator Certified Associate EnterpriseDB Certified PostgreSQL 9.3 Associate
