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

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) 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>
> 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
>>
>>

--
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