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

Reply via email to