User-Agent: K-9 Mail for Android
In-Reply-To: <53AB4551.4070207@optionshouse.com>
References: <53AB2CB1.8080201@comcast.net> <53AB35CC.10202@optionshouse.com>
 <1801a5d4-c3f1-4c0c-9c2c-ffb9d7f723a3@email.android.com>
 <53AB4551.4070207@optionshouse.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="----8LEEMQB8Z695TLTIYKZ3455DYUTLLQ"
Content-Transfer-Encoding: 8bit
Subject: Re: how to improve perf of 131MM row table?
From: Aaron Weber <aweber@comcast.net>
Date: Wed, 25 Jun 2014 18:29:40 -0400
To: Shaun Thomas <sthomas@optionshouse.com>,
 "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Message-ID: <05c5e35e-3cd8-4ff7-bb65-ef0df61b345c@email.android.com>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

------8LEEMQB8Z695TLTIYKZ3455DYUTLLQ
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8

Will get what you asked for ASAP. Thanks for your time. 
-- 
Aaron

On June 25, 2014 5:55:29 PM EDT, Shaun Thomas <sthomas@optionshouse.com> wrote:
>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

------8LEEMQB8Z695TLTIYKZ3455DYUTLLQ
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

<html><head></head><body>Will get what you asked for ASAP. Thanks for your time. <br>
-- <br>
Aaron<br><br><div class="gmail_quote">On June 25, 2014 5:55:29 PM EDT, Shaun Thomas &lt;sthomas@optionshouse.com&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 06/25/2014 04:40 PM, Aaron Weber wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> In the meantime, I guess I wasn't clear about some other particulars<br /> The query's where clause is only an "IN", with a list of id's (those<br /> I mentioned are the PK), and the join is explicitly on the PK (so,<br /> indexed).<br /></blockquote><br />Indexed doesn't mean indexed if the wrong datatypes are used. We need to <br />see the table and index definitions, and a sample query with EXPLAIN <br />ANALYZE output.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> An IN with 50 int values took 23sec to return (by way of example).<br /></blockquote><br />To me, this sounds like a sequence scan, or one of your key matches so <br />many rows, the random seeks are throwing off your performance. Of <br />course,
I can't confirm that without EXPLAIN output.<br /></pre></blockquote></div></body></html>
------8LEEMQB8Z695TLTIYKZ3455DYUTLLQ--