Re: Reduce WAL logging of INSERT SELECT

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reduce WAL logging of INSERT SELECT
Date: 2011-08-05 14:36:44
Message-ID: CA+U5nMKoGrg9uZaF9gsy45WoBQ-ds6Q6Vv3JUtxpLc758+TGkg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 4, 2011 at 11:07 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Simon Riggs wrote:
>> On Thu, Aug 4, 2011 at 10:46 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>
>> > Right. ?I brought up SELECT INTO because you could make the argument
>> > that INSERT ... SELECT is not a utility command like the other ones and
>> > therefore can't be done easily, but CREATE TABLE AS is internal SELECT
>> > INTO and implemented in execMain.c, which I think is where INSERT ...
>> > SELECT would also be implemented.
>>
>> What you should be asking is whether the optimisation would be
>> effective for INSERT SELECT, or even test it.
>>
>> My observation is that the optimisation is only effective for very
>> large loads that cause I/O. As RAM sizes get bigger, I'm inclined to
>> remove the optimisation and make it optional since it is ineffective
>> in many cases and negative benefit for smaller cases.
>
> I am confused how generating WAL traffic that is larger than the heap
> file we are fsync'ing can possibly be slower.

I'm telling you what I know to be true as an assistance to you.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-08-05 14:53:21 Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https
Previous Message Robert Haas 2011-08-05 12:32:16 Re: psql: display of object comments