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-04 21:59:24 |
Message-ID: | CA+U5nMJ6K7AaV=42QB3YmhdSrq6_TzcU=o0kPKKzkumsWL7Ldw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2011-08-04 22:01:45 | Re: PQescapeByteaConn - returns wrong string for PG9.1 Beta3 |
Previous Message | Bruce Momjian | 2011-08-04 21:46:35 | Re: Reduce WAL logging of INSERT SELECT |