Skip site navigation (1) Skip section navigation (2)

Re: Sequencial scan in a JOIN

From: Shaun Thomas <sthomas(at)optionshouse(dot)com>
To: Andrew Jaimes <andrewjaimes(at)hotmail(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Sequencial scan in a JOIN
Date: 2012-06-05 13:15:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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


See for terms and conditions related to this email

In response to


pgsql-performance by date

Next:From: Andrew JaimesDate: 2012-06-05 13:31:19
Subject: Re: Sequencial scan in a JOIN
Previous:From: Andrew JaimesDate: 2012-06-05 12:48:41
Subject: Sequencial scan in a JOIN

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group