Re: Performance on Bulk Insert to Partitioned Table

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Charles Gomes <charlesrg(at)outlook(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Performance on Bulk Insert to Partitioned Table
Date: 2012-12-20 22:31:44
Message-ID: CAMkU=1zMNyCUMFGjsJM69FQbY9pYBr9jjW3c5jSe3vwABMudgQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, Dec 20, 2012 at 9:29 AM, Charles Gomes <charlesrg(at)outlook(dot)com> wrote:
> Hello guys
>
>
>
> I’m doing 1.2 Billion inserts into a table partitioned in
> 15.
>
>
>
> When I target the MASTER table on all the inserts and let
> the trigger decide what partition to choose from it takes 4 hours.
>
> If I target the partitioned table directly during the
> insert I can get 4 times better performance. It takes 1 hour.

How do you target them directly? By implementing the
"trigger-equivalent-code" in the application code tuple by tuple, or
by pre-segregating the tuples and then bulk loading each segment to
its partition?

What if you get rid of the partitioning and just load data to the
master, is that closer to 4 hours or to 1 hour?

...
>
>
> What I noticed that iostat is not showing an I/O bottle
> neck.
>
> iostat –xN 1
>
> Device:
> rrqm/s wrqm/s r/s
> w/s rsec/s wsec/s avgrq-sz avgqu-sz
> await svctm %util
>
> Pgresql--data
> 0.00 0.00 0.00
> 8288.00 0.00 66304.00
> 8.00 60.92 7.35
> 0.01 4.30

8288 randomly scattered writes per second sound like enough to
bottleneck a pretty impressive RAID. Or am I misreading that?

Cheers,

Jeff

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Charles Gomes 2012-12-20 22:43:22 Re: Performance on Bulk Insert to Partitioned Table
Previous Message Huan Ruan 2012-12-20 21:16:24 Re: hash join vs nested loop join