Re: Seq scan on 10million record table.. why?

On 10/30/2012 07:15 AM, Vincenzo Melandri wrote:

> Merge Join (cost=2604203.98..2774528.51 rows=129904 width=20)
> Merge Cond: (((( big_table.key1)::numeric) =
> data_sequences_table.key1) AND ((( big_table.key2)::numeric) =
> data_sequences_table.key2))
> -> Sort (cost=2602495.47..2635975.81 rows=13392135 width=20)
> Sort Key: ((big_table.key1)::numeric), ((big_table.key2)::numeric)
> -> Seq Scan on big_table (cost=0.00..467919.35 rows=13392135 width=20)
> -> Sort (cost=1708.51..1709.48 rows=388 width=32)
> Sort Key: data_sequences_table.key1, data_sequences_table.key2
> -> Seq Scan on data_sequences_table (cost=0.00..1691.83
> rows=388 width=32)
> Filter: (import_id = 1351592072::numeric)

As always, we need to see an EXPLAIN ANALYZE, not just an EXPLAIN. We
also need to know the version of PostgreSQL and your server settings.
Please refer to this:

http://wiki.postgresql.org/wiki/Slow_Query_Questions

I see a lot of NUMERIC conversions in there, which suggests you're using
NUMERIC for your keys. That's not really recommended practice, but also
suggests the possibility that all your types are not the same. So it
would be very helpful to also see the actual CREATE TABLE, and CREATE
INDEX statements for those tables.

We can't help you with this limited information. Sorry.

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604
312-444-8534
sthomas(at)optionshouse(dot)com

______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email