pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Aaron Weber <aweber@comcast.net>
To: Shaun Thomas <sthomas@optionshouse.com>
To: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: how to improve perf of 131MM row table?
Date: Wed, 25 Jun 2014 17:40:47 -0400
Message-ID: <1801a5d4-c3f1-4c0c-9c2c-ffb9d7f723a3@email.android.com> (raw)
In-Reply-To: <53AB35CC.10202@optionshouse.com>
References: <53AB2CB1.8080201@comcast.net>
	<53AB35CC.10202@optionshouse.com>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-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@optionshouse.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@optionshouse.com
>
>______________________________________________
>
>See http://www.peak6.com/email_disclaimer/ for terms and conditions
>related to this email

view thread (25+ messages)  latest in thread

Message-ID: <1801a5d4-c3f1-4c0c-9c2c-ffb9d7f723a3@email.android.com>
Permalink:  ../1801a5d4-c3f1-4c0c-9c2c-ffb9d7f723a3@email.android.com/
Also on:    postgresql.org/message-id/1801a5d4-c3f1-4c0c-9c2c-ffb9d7f723a3@email.android.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: aweber@comcast.net, sthomas@optionshouse.com
  Subject: Re: how to improve perf of 131MM row table?
  In-Reply-To: <1801a5d4-c3f1-4c0c-9c2c-ffb9d7f723a3@email.android.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox