Re: Sequencial scan in a JOIN
От | Shaun Thomas |
---|---|
Тема | Re: Sequencial scan in a JOIN |
Дата | |
Msg-id | 4FCE0681.5040306@optionshouse.com обсуждение исходный текст |
Ответ на | Sequencial scan in a JOIN (Andrew Jaimes <andrewjaimes@hotmail.com>) |
Ответы |
Re: Sequencial scan in a JOIN
|
Список | pgsql-performance |
On 06/05/2012 07:48 AM, Andrew Jaimes wrote: > ' -> Hash Join (cost=10.93..99795.09 rows=242803 width=0) (actual > time=0.541..2249.027 rows=33 loops=1)' > ' Hash Cond: ((a_activity.activequeueid = l_userqueue.queueid) > AND (a_activity.sbuid = e_usersessions.sbuid))' > ' -> Seq Scan on a_activity (cost=0.00..88462.52 rows=1208167 > width=22) (actual time=0.010..1662.142 I'd be willing to bet your stats are way, way off. It expected 242,803 rows in the hash, but only got 33. In that kind of scenario, I could easily see the planner choosing a sequence scan over an index scan, as doing that many index seeks would be much more expensive than scanning the table. What's your default_statistics_target, and when is the last time you analyzed the tables in this query? -- 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 по дате отправления: