Re: how to improve perf of 131MM row table?

From: Aaron Weber <aweber(at)comcast(dot)net>
To: Shaun Thomas <sthomas(at)optionshouse(dot)com>, "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:40:47
Message-ID: 1801a5d4-c3f1-4c0c-9c2c-ffb9d7f723a3@email.android.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

I will gather the other data tonight. Thank you.

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).

Thus, there should be only the explicit matches to the in clause returned, and if postgresql isn't using the unique index on that column, I would be very shocked (to the point I would suggest there is a bug somewhere).

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

Thanks again.
--
Aaron

On June 25, 2014 4:49:16 PM EDT, Shaun Thomas <sthomas(at)optionshouse(dot)com> wrote:
>On 06/25/2014 03:10 PM, AJ Weber wrote:
>
>> I have a relatively sizable postgresql 9.0.2 DB with a few large
>tables
>> (keep in mind "large" is relative, I'm sure there are plenty larger
>out
>> there).
>
>Regardless of any help we might offer regarding this, you need to
>upgrade your installation to 9.0.17. You are behind by several
>performance, security, and integrity bugfixes, some of which address
>critical corruption bugs related to replication.
>
>> One of my queries that seems to be bogging-down performance is a join
>> between two tables on each of their BIGINT PK's (so they have default
>> unique constraint/PK indexes on them). One table is a detail table
>for
>> the other.
>
>This isn't enough information. Just knowing the relative sizes of the
>tables doesn't tell us which columns are indexed, whether or not the
>query is using those indexes, how many rows usually match, which
>queries
>are performing badly, and so on.
>
>Please refer to this page to ask performance related questions:
>
>https://wiki.postgresql.org/wiki/Slow_Query_Questions
>
>Without much of this information, we'd only be speculating.
>
>--
>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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Merlin Moncure 2014-06-25 21:48:01 Re: Guidelines on best indexing strategy for varying searches on 20+ columns
Previous Message Shaun Thomas 2014-06-25 20:49:16 Re: how to improve perf of 131MM row table?