Postgres Pro
Downloads
Home   >   mailing lists

Re: Slow HashAggregate/cache access - Mailing list pgsql-performance

From Alexandre de Arruda Paes
Subject Re: Slow HashAggregate/cache access
Date
Msg-id CAGewt-ubvhoxET77ba32c9L6zz09sqPTYizF3CCCfY8VHJFJWw@mail.gmail.com
Whole thread Raw
In response to Re: Slow HashAggregate/cache access  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-performance
Tree view

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 by date:

Previous
From: David Rowley
Date:
Subject: Re: Slow HashAggregate/cache access
Next
From: Alexandre de Arruda Paes
Date:
Subject: Re: Slow HashAggregate/cache access