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

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

2021-01-19 Thread Hellmuth Vargas

Hola Lista

Realiza la prueba correspondiente y efectivamente, en la versión 13.1, ya
emplea el índice para resolver la consulta... Muchas Gracias!

psql (11.7)
Type "help" for help.

bd_dev=# select version();
 version
-
 PostgreSQL 11.7 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7
20120313 (Red Hat 4.4.7-23), 64-bit
(1 row)

bd_dev=# explain analyze select tipo_evento, max(id)
bd_dev-# from test.ivr
bd_dev-# group by 1
bd_dev-# ;

 QUERY PLAN

--
--
 Finalize GroupAggregate  (cost=218860.30..218875.25 rows=59 width=18)
(actual time=21157.994..21158.119 r
ows=70 loops=1)
   Group Key: tipo_evento
   ->  Gather Merge  (cost=218860.30..218874.07 rows=118 width=18) (actual
time=21157.974..21158.173 rows=
209 loops=1)
 Workers Planned: 2
 Workers Launched: 2
 ->  Sort  (cost=217860.28..217860.42 rows=59 width=18) (actual
time=21114.952..21114.958 rows=70
loops=3)
   Sort Key: tipo_evento
   Sort Method: quicksort  Memory: 29kB
   Worker 0:  Sort Method: quicksort  Memory: 29kB
   Worker 1:  Sort Method: quicksort  Memory: 29kB
   ->  Partial HashAggregate  (cost=217857.95..217858.54
rows=59 width=18) (actual time=21114.
797..21114.809 rows=70 loops=3)
 Group Key: tipo_evento
 ->  Parallel Seq Scan on ivr  (cost=0.00..196204.30
rows=4330730 width=18) (a
ctual time=3.283..20220.741 rows=3464613 loops=3)
 Planning Time: 33.484 ms
 Execution Time: 21167.712 ms
(15 rows)



psql (13.1)
Type "help" for help.

bd_dev=# select version();
 version
-
 PostgreSQL 13.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7
20120313 (Red Hat 4.4.7-23), 64-bit
(1 row)



bd_dev=# explain analyze select tipo_evento, max(id)
from test.ivr
group by 1
;

 QUERY PLAN

--
---
 Finalize GroupAggregate  (cost=1000.12..85467.15 rows=59 width=18) (actual
time=710.868..6729.597 rows=70
 loops=1)
   Group Key: tipo_evento
   ->  Gather Merge  (cost=1000.12..85466.85 rows=118 width=18) (actual
time=398.333..6729.385 rows=169 lo
ops=1)
 Workers Planned: 2
 Workers Launched: 2
 ->  Partial GroupAggregate  (cost=0.11..84454.21 rows=59 width=18)
(actual time=335.542..5644.643
 rows=56 loops=3)
   Group Key: tipo_evento
   ->  Parallel Index Only Scan using idx_ivr_tipo_evento on
ivr  (cost=0.11..80123.30
 rows=4330738 width=18) (actual time=7.069..5184.099 rows=3464613 loops=3)
 Heap Fetches: 0
 Planning Time: 324.654 ms
 Execution Time: 6746.178 ms
(11 rows)

El lun, 18 de ene. de 2021 a la(s) 07:14, Hellmuth Vargas (hiv...@gmail.com)
escribió:

> Hola Alvaro
>
> Muchas Gracias por el dato!  no he evaluado esta consulta en  pg13, voy a
> montar  un  ambiente  para ver su funcionamiento.
>
> El vie, 15 de ene. de 2021 a la(s) 18:05, Alvaro Herrera (
> alvhe...@2ndquadrant.com) escribió:
>
>> Hellmuth Vargas escribió:
>> > Hola Alvaro
>> >
>> > Mil gracias por la respuesta, pues valdría la pena apoyar el parche
>> porque
>> > sera una forma rápida de obtener algunas funciones agregadas (máximos,
>> > mínimos) agrupados por "categorias" directamente desde un indice
>> asociado
>> > el cual si esta ordenado debe debería resolverlo rápidamente este
>> tipo
>> > de  consultas son muy comunes... que opinan?
>>
>> Hola, estaba mirando el archivo de la lista por otras razones y vi este
>> mensaje.  Pensé que sería buena idea comentar que el parche que
>> mencionaba en ese momento fue incluido en Postgres 13, por si aún no te
>> has subido de versión, para que veas qué tal te funciona.
>>
>> Saludos
>>
>> PD:
>> http://postgr.es/m/flat/can3qy4pfnu0pfhbgf8nanjzc5vddzjoyepd7cmuprbgwb3_...@mail.gmail.com
>> por si no tienes los mails de ese tiempo
>>
>> --
>> Álvaro Herrera39°49'30"S 73°17'W
>> "Saca el libro que tu religión considere como el indicado para encontrar
>> la
>> oración que traiga paz a tu alma. Luego rebootea el computador
>> y ve si funciona" (Carlos Duclós)
>>
>
>
> --
> 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
>
>

-- 
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator

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

2021-01-18 Thread Hellmuth Vargas

Hola Alvaro

Muchas Gracias por el dato!  no he evaluado esta consulta en  pg13, voy a
montar  un  ambiente  para ver su funcionamiento.

El vie, 15 de ene. de 2021 a la(s) 18:05, Alvaro Herrera (
alvhe...@2ndquadrant.com) escribió:

> Hellmuth Vargas escribió:
> > Hola Alvaro
> >
> > Mil gracias por la respuesta, pues valdría la pena apoyar el parche
> porque
> > sera una forma rápida de obtener algunas funciones agregadas (máximos,
> > mínimos) agrupados por "categorias" directamente desde un indice asociado
> > el cual si esta ordenado debe debería resolverlo rápidamente este
> tipo
> > de  consultas son muy comunes... que opinan?
>
> Hola, estaba mirando el archivo de la lista por otras razones y vi este
> mensaje.  Pensé que sería buena idea comentar que el parche que
> mencionaba en ese momento fue incluido en Postgres 13, por si aún no te
> has subido de versión, para que veas qué tal te funciona.
>
> Saludos
>
> PD:
> http://postgr.es/m/flat/can3qy4pfnu0pfhbgf8nanjzc5vddzjoyepd7cmuprbgwb3_...@mail.gmail.com
> por si no tienes los mails de ese tiempo
>
> --
> Álvaro Herrera39°49'30"S 73°17'W
> "Saca el libro que tu religión considere como el indicado para encontrar la
> oración que traiga paz a tu alma. Luego rebootea el computador
> y ve si funciona" (Carlos Duclós)
>


-- 
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

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

2019-11-29 Thread Alvaro Herrera

Hellmuth Vargas escribió:
> Hola Anthony
> 
> NO, eso es claro que sale mas costoso.. pero la pregunta va a que si tengo
> un indice por centro y id (este  ordenado desc)  no debería  poder sacar el
> máximo por cada centro empleando exclusivamente el indice?

La razón es que no está implementado hacerlo más rápido.  Hay un parche
propuesto para la versión 13 que me parece resuelve tu problema

https://commitfest.postgresql.org/25/1124/

Lo probé con la tabla vacía (no diste un mecanismo para generar datos) y
seteando enable_seqscan off me da este plan:

   QUERY PLAN   
 
─
 GroupAggregate  (cost=0.14..45.64 rows=50 width=524)
   Group Key: centrocodigo
   ->  Index Only Scan using idx_oportunidadcitas_desc on oportunidadcitas  
(cost=0.14..44.89 rows=50 width=524)
(3 filas)


que supongo que es lo que buscas, pero no estoy seguro.

Sugiero que verifiques si el parche hace mejor el plan, y si es así,
le damos un +1 a ese parche (que lleva harto tiempo pendiente)

saludos


-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

2019-11-29 Thread Diego

Atentis que no hay un idx por id, sino que es el segundo campo de uno y 
del otro lado es la PK de la tabla



On 29/11/19 13:31, Anthony Sotolongo wrote:


Bueno en realidad te trae los datos empleando el indice, pero es más 
costoso que hacerlo recorriendo la tabla entera para las estadisticas 
que el tiene,


y para su algoritmo de obtener los datos tambien lo es,  pues demora 
un poco mas con el indices, pues tiene que hacer  Bitmap Index Scan y 
Bitmap Heap Scan


Saludos



El 29-11-19 a las 12:55, Hellmuth Vargas escribió:

Hola Anthony

NO, eso es claro que sale mas costoso.. pero la pregunta va a que si 
tengo un indice por centro y id (este  ordenado desc)  no debería  
poder sacar el máximo por cada centro empleando exclusivamente el 
indice?




El vie., 29 de nov. de 2019 a la(s) 10:54, Anthony Sotolongo 
(asotolo...@gmail.com ) escribió:


Creo que tu respuesta está ahí, para las estadísticas que tiene
esa tabla es más efectivo hacer un seq scan que usar el indice

Saludos

El vie., 29 de nov. de 2019 12:45 p. m., Hellmuth Vargas
mailto:hiv...@gmail.com>> escribió:


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
(asotolo...@gmail.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

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

2019-11-29 Thread Anthony Sotolongo

Bueno en realidad te trae los datos empleando el indice, pero es más 
costoso que hacerlo recorriendo la tabla entera para las estadisticas 
que el tiene,


y para su algoritmo de obtener los datos tambien lo es,  pues demora un 
poco mas con el indices, pues tiene que hacer  Bitmap Index Scan y 
Bitmap Heap Scan


Saludos



El 29-11-19 a las 12:55, Hellmuth Vargas escribió:

Hola Anthony

NO, eso es claro que sale mas costoso.. pero la pregunta va a que si 
tengo un indice por centro y id (este  ordenado desc)  no debería  
poder sacar el máximo por cada centro empleando exclusivamente el indice?




El vie., 29 de nov. de 2019 a la(s) 10:54, Anthony Sotolongo 
(asotolo...@gmail.com ) escribió:


Creo que tu respuesta está ahí, para las estadísticas que tiene
esa tabla es más efectivo hacer un seq scan que usar el indice

Saludos

El vie., 29 de nov. de 2019 12:45 p. m., Hellmuth Vargas
mailto:hiv...@gmail.com>> escribió:


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
(asotolo...@gmail.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

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

2019-11-29 Thread Hellmuth Vargas

Hola Anthony

NO, eso es claro que sale mas costoso.. pero la pregunta va a que si tengo
un indice por centro y id (este  ordenado desc)  no debería  poder sacar el
máximo por cada centro empleando exclusivamente el indice?



El vie., 29 de nov. de 2019 a la(s) 10:54, Anthony Sotolongo (
asotolo...@gmail.com) escribió:

> Creo que tu respuesta está ahí, para las estadísticas que tiene esa tabla
> es más efectivo hacer un seq scan que usar el indice
>
> Saludos
>
> El vie., 29 de nov. de 2019 12:45 p. m., Hellmuth Vargas 
> escribió:
>
>>
>> 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 (
>> asotolo...@gmail.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
>>
>>

-- 
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

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

2019-11-29 Thread Anthony Sotolongo

Creo que tu respuesta está ahí, para las estadísticas que tiene esa tabla
es más efectivo hacer un seq scan que usar el indice

Saludos

El vie., 29 de nov. de 2019 12:45 p. m., Hellmuth Vargas 
escribió:

>
> 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 (
> asotolo...@gmail.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
>
>

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

2019-11-29 Thread Hellmuth Vargas

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 (
asotolo...@gmail.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

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

2019-11-29 Thread Anthony Sotolongo

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

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

2019-11-29 Thread Hellmuth Vargas

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  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

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

2019-11-29 Thread Olivier Gautherot

Hola Hellmut,

On Fri, Nov 29, 2019 at 12:10 PM Hellmuth Vargas  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
>
>

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

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

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

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

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

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

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

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

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

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

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

11 matches

Site Navigation

Mail list logo

Footer information