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

Bueno en realidad te trae los datos empleando el indice, pero es más
costoso que hacerlo recorriendo la tabla entera para las estadisticas
que el tiene,

y para su algoritmo de obtener los datos tambien lo es,  pues demora un
poco mas con el indices, pues tiene que hacer  Bitmap Index Scan y
Bitmap Heap Scan

Saludos

El 29-11-19 a las 12:55, Hellmuth Vargas escribió:
> 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
> (asotolongo(at)gmail(dot)com <mailto:asotolongo(at)gmail(dot)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
> <hivs77(at)gmail(dot)com <mailto: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 <mailto: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
>
>
>
> --
> 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
>