From: | Olivier Gautherot <ogautherot(at)gautherot(dot)net> |
---|---|
To: | Hellmuth Vargas <hivs77(at)gmail(dot)com> |
Cc: | Lista Postgres ES <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: porque no emplea indice para algunas funciones agregadas (max,min) |
Date: | 2019-11-29 15:24:23 |
Message-ID: | CAJ7S9TUae2Zzh0CjKGYtdMy6J73oHo=nEVErJQVoaudo8sC8kg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Hellmuth Vargas | 2019-11-29 15:33:26 | Re: porque no emplea indice para algunas funciones agregadas (max,min) |
Previous Message | Hellmuth Vargas | 2019-11-29 15:09:52 | porque no emplea indice para algunas funciones agregadas (max,min) |