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 ( ogauthe...@gautherot.net) escribió: > Hola Hellmut, > > On Fri, Nov 29, 2019 at 12:10 PM Hellmuth Vargas <hiv...@gmail.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