Re: Seq scan on 10million record table.. why?
| От | Shaun Thomas |
|---|---|
| Тема | Re: Seq scan on 10million record table.. why? |
| Дата | |
| Msg-id | 508FDBBC.2010807@optionshouse.com обсуждение исходный текст |
| Ответ на | Seq scan on 10million record table.. why? (Vincenzo Melandri <vmelandri@imolinfo.it>) |
| Список | pgsql-performance |
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@optionshouse.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
В списке pgsql-performance по дате отправления: