Re: porque no emplea indice para algunas funciones agregadas (max,min)

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 <hivs77(at)gmail(dot)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 (
> asotolongo(at)gmail(dot)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
>
>