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
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 |