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

Hola Olivier

Gracias por contestar, si lo ejecuto tal cual me sale el siguiente error:

ERROR: column "id" must appear in the GROUP BY clause or be used in an
aggregate function
LINE 1: ...MING off )select distinct on (centrocodigo) centrocodigo, id...

ajustándolo asi:

select distinct on (centrocodigo) centrocodigo, id as ultimo
from oportunidadcitas
group by centrocodigo,id
order by centrocodigo, id

obtengo esto:

Unique (cost=15382.47..15382.52 rows=55 width=21) (actual
time=212.218..212.221 rows=5 loops=1)
-> Sort (cost=15382.47..15382.50 rows=55 width=21) (actual
time=212.218..212.219 rows=11 loops=1)
Sort Key: centrocodigo , id DESC
Sort Method: quicksort Memory: 25kB
-> HashAggregate (cost=15381.93..15382.15 rows=55 width=21)
(actual time=212.195..212.196 rows=11 loops=1)
Group Key: centrocodigo , id
-> Seq Scan on oportunidadcitas (cost=0.00..15069.14
rows=312786 width=21) (actual time=0.004..82.925 rows=312765 loops=1)
Planning time: 0.108 ms
Execution time: 212.253 ms

El vie., 29 de nov. de 2019 a la(s) 10:24, Olivier Gautherot (
ogautherot(at)gautherot(dot)net) escribió:

> Hola Hellmut,
>
> On Fri, Nov 29, 2019 at 12:10 PM Hellmuth Vargas <hivs77(at)gmail(dot)com> wrote:
>
>>
>> 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
>>
>>
> Podrías probar:
>
> select distinct on (centrocodigo) centrocodigo, id as ultimo
> from oportunidadcitas
> group by centrocodigo
> order by centrocodigo, id
>
>
>
>> 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