Re: WAL + SSD = slow inserts?

From: Skarsol <skarsol(at)gmail(dot)com>
To: bricklen <bricklen(at)gmail(dot)com>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: WAL + SSD = slow inserts?
Date: 2013-12-06 05:55:27
Message-ID: CAMt8e=GPCAss1ft-aW0W5CvMORTp95Pyzw9OcVbEUjtKHCS4bw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, Dec 5, 2013 at 1:19 PM, bricklen <bricklen(at)gmail(dot)com> wrote:

>
> On Thu, Dec 5, 2013 at 10:08 AM, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>wrote:
>
>> Rules have a lot of overhead. Is there a reason you're not using
>> defaults or triggers?
>>
>
> Or for even less overhead, load the partitions directly, and preferably
> use "DEFAULT nextval('some_sequence')" as Scott mentioned.
>
>
The rule is being used to return the id of the insert, it's not part of the
partitioning itself. The id is generated with default nextval. I've looked
at using returning instead but that will require a large refactoring of the
codebase and seems to have issues when combined with the partitioning. The
partitioning is done with a BEFORE INSERT ON trigger. The trigger proc
doesn't do any selects, it's just based on the contents of the insert
itself.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Pavel Stehule 2013-12-06 05:58:36 Re: One huge db vs many small dbs
Previous Message jacket41142 2013-12-06 02:10:26 select count(distinct ...) is slower than select distinct in about 5x