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

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