Re: Slow HashAggregate/cache access

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