Message-ID: <53AB4551.4070207@optionshouse.com>
Date: Wed, 25 Jun 2014 16:55:29 -0500
From: Shaun Thomas <sthomas@optionshouse.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Aaron Weber <aweber@comcast.net>, "pgsql-performance@postgresql.org"
 <pgsql-performance@postgresql.org>
Subject: Re: how to improve perf of 131MM row table?
References: <53AB2CB1.8080201@comcast.net> <53AB35CC.10202@optionshouse.com>
 <1801a5d4-c3f1-4c0c-9c2c-ffb9d7f723a3@email.android.com>
In-Reply-To: <1801a5d4-c3f1-4c0c-9c2c-ffb9d7f723a3@email.android.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
content-transfer-encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 06/25/2014 04:40 PM, Aaron Weber wrote:

> In the meantime, I guess I wasn't clear about some other particulars
> The query's where clause is only an "IN", with a list of id's (those
> I mentioned are the PK), and the join is explicitly on the PK (so,
> indexed).

Indexed doesn't mean indexed if the wrong datatypes are used. We need to 
see the table and index definitions, and a sample query with EXPLAIN 
ANALYZE output.

> An IN with 50 int values took 23sec to return (by way of example).

To me, this sounds like a sequence scan, or one of your key matches so 
many rows, the random seeks are throwing off your performance. Of 
course, I can't confirm that without EXPLAIN output.

-- 
Shaun Thomas
OptionsHouse, LLC | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas@optionshouse.com

______________________________________________

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


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance