| From: | Shaun Thomas <sthomas(at)optionshouse(dot)com> |
|---|---|
| To: | Aaron Weber <aweber(at)comcast(dot)net>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: how to improve perf of 131MM row table? |
| Date: | 2014-06-25 21:55:29 |
| Message-ID: | 53AB4551.4070207@optionshouse.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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(at)optionshouse(dot)com
______________________________________________
See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Aaron Weber | 2014-06-25 22:29:40 | Re: how to improve perf of 131MM row table? |
| Previous Message | Merlin Moncure | 2014-06-25 21:48:01 | Re: Guidelines on best indexing strategy for varying searches on 20+ columns |