Re: Slow HashAggregate/cache access

Поиск
Список
Период
Сортировка
От Alexandre de Arruda Paes
Тема Re: Slow HashAggregate/cache access
Дата
Msg-id CAGewt-ubvhoxET77ba32c9L6zz09sqPTYizF3CCCfY8VHJFJWw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Slow HashAggregate/cache access  (David Rowley <david.rowley@2ndquadrant.com>)
Список pgsql-performance
Дерево обсуждения

The query in question is likely performing badly because of this:

                     ->  Seq Scan on fr13t1  (cost=0.00..25072.50 rows=311800 width=21) (actual time=0.007..115.766 rows=311800 loops=1)
                           Filter: (fr01codemp = '1'::smallint)
                           Buffers: shared hit=21175

Just how selective is fr01codemp = '1'::smallint ? Is there an index on that column ?


Hi David,

In this case, fr13t1 has only value '1' in all fr01codemp:

copro95=# select fr01codemp,count(*) from fr13t1 group by fr01codemp;
 fr01codemp | count  
------------+--------
          1 | 311800
(1 row)

Table "public.fr13t1"
   Column   |            Type             | Modifiers 
------------+-----------------------------+-----------
 fr01codemp | smallint                    | not null
 fr02codigo | numeric(10,0)               | not null
 fr13dtlanc | date                        | not null
 fr13sequen | smallint                    | not null
(...)
Indexes:
    "fr13t1_pkey" PRIMARY KEY, btree (fr01codemp, fr02codigo, fr13dtlanc, fr13sequen)
    "ifr13t1" btree (fr01codemp, fr07cod)
    "ifr13t12" btree (co18codord)
    "ifr13t14" btree (fr01codemp, fr52mot)
(...)
 
If planner needs to scan all table, can indexscan/indexonlyscan can take any advantage ? 

Besta regards,

Alexandre


В списке pgsql-performance по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Slow HashAggregate/cache access
Следующее
От: Alexandre de Arruda Paes
Дата:
Сообщение: Re: Slow HashAggregate/cache access