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

Atentis que no hay un idx por id, sino que es el segundo campo de uno y
del otro lado es la PK de la tabla

On 29/11/19 13:31, Anthony Sotolongo wrote:
>
> 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
>>