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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux