Re: Reduce WAL logging of INSERT SELECT

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Reduce WAL logging of INSERT SELECT
Дата
Msg-id 201108042207.p74M7NG29088@momjian.us
обсуждение исходный текст
Ответ на Re: Reduce WAL logging of INSERT SELECT  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Reduce WAL logging of INSERT SELECT  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Reduce WAL logging of INSERT SELECT  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
Simon Riggs wrote:
> On Thu, Aug 4, 2011 at 10:46 PM, Bruce Momjian <bruce@momjian.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.  Are you just throwing out
an idea to try to make me prove it?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: PQescapeByteaConn - returns wrong string for PG9.1 Beta3
Следующее
От: Alex Hunsaker
Дата:
Сообщение: Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https