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

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Aaron Weber <aweber(at)comcast(dot)net>
Cc: 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-26 20:14:55
Message-ID: CAMkU=1yxskTJ8ZQQZvBqJ82Jk_R_NoeuCKkYv+8aunT191=Htw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Jun 25, 2014 at 2:40 PM, Aaron Weber <aweber(at)comcast(dot)net> wrote:
> 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).

The PK of the master table and the PK of the detail table cannot be
the same thing, or they would not have a master-detail relationship.
One side has to be an FK, not a PK.

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

If that is 50 PKs from the master table, it would be about 1000 on the
detail table. If you have 5600 rpm drives and every detail row
requires one index leaf page and one table page to be read from disk,
then 23 seconds is right on the nose. Although they shouldn't require
a different leaf page each because all entries for the same master row
should be adjacent in the index, so that does sound a little high if
this is the only thing going on.

Cheers,

Jeff

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Shaun Thomas 2014-06-26 20:26:43 Re: how to improve perf of 131MM row table?
Previous Message AJ Weber 2014-06-26 18:01:59 Re: how to improve perf of 131MM row table?