Re: how to improve perf of 131MM row table?

 From psql (same session as previous \d output) --

  Hash Join  (cost=328182.35..548154.83 rows=52790 width=187) (actual 
time=4157.886..4965.466 rows=1071 loops=1)
    Hash Cond: (prop.node_id = node.id)
    Buffers: shared hit=146711 read=23498, temp read=23676 written=23646
    ->  Bitmap Heap Scan on alf_node_properties prop 
(cost=1253.19..189491.88 rows=52790 width=179) (actual time=0.429..1.154 
rows=1071 loops=1)
          Recheck Cond: (node_id = ANY 
('{175769,175771,175781,175825,175881,175893,175919,175932,175963,175999,176022,176079,176099,176115,176118,176171,176181,176217,176220,176243,176283,176312,176326,176335,176377,176441,176444,176475,176530,176570,176623,176674,176701,176730,176748,176763,176771,176808,176836,176851,176864,176881,176929,176945,176947,176960,177006,177039,177079,177131,177144}'::bigint[]))
          Buffers: shared hit=278
          ->  Bitmap Index Scan on fk_alf_nprop_n (cost=0.00..1240.00 
rows=52790 width=0) (actual time=0.411..0.411 rows=1071 loops=1)
                Index Cond: (node_id = ANY 
('{175769,175771,175781,175825,175881,175893,175919,175932,175963,175999,176022,176079,176099,176115,176118,176171,176181,176217,176220,176243,176283,176312,176326,176335,176377,176441,176444,176475,176530,176570,176623,176674,176701,176730,176748,176763,176771,176808,176836,176851,176864,176881,176929,176945,176947,176960,177006,177039,177079,177131,177144}'::bigint[]))
                Buffers: shared hit=207
    ->  Hash  (cost=227265.29..227265.29 rows=5733429 width=16) (actual 
time=4156.075..4156.075 rows=5734255 loops=1)
          Buckets: 65536  Batches: 16  Memory Usage: 16888kB
          Buffers: shared hit=146433 read=23498, temp written=23609
          ->  Seq Scan on alf_node node  (cost=0.00..227265.29 
rows=5733429 width=16) (actual time=0.004..1908.493 rows=5734255 loops=1)
                Buffers: shared hit=146433 read=23498
  Total runtime: 4967.674 ms
(15 rows)

On 6/26/2014 10:37 AM, Shaun Thomas wrote:
> On 06/26/2014 09:22 AM, AJ Weber wrote:
>
>> I sent the details as identified by pgAdmin III.
>
> Interesting. Either there is a bug in pgAdmin, or you're connecting to 
> a different database that is missing the primary key. What is the 
> EXPLAIN ANALYZE output if you execute the query you sent on a psql 
> prompt?
>
>>      "alf_node_pkey" PRIMARY KEY, btree (id) CLUSTER
>> would indicate to me that there is a PK on alf_node table, it is on
>> column "id", it is of type btree, and the table is clustered around that
>> index.
>>
>> Am I reading this totally wrong?
>
> No, that's right. But that wasn't in the SQL you sent. In fact, 
> there's a lot of stuff missing in that output.
>
> Try running the EXPLAIN ANALYZE using the same psql connection you 
> used to retrieve the actual table structure just now. I suspect you've 
> accidentally connected to the wrong database. If it's still doing the 
> sequence scan, we'll have to dig deeper.
>