From: | Jeff Davis <pgsql(at)j-davis(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 00:53:48 |
Message-ID: | 1312505628.22189.6.camel@jdavis-ux.asterdata.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2011-08-04 at 17:46 -0400, Bruce Momjian 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.
The above statement is a little confusing, so let me start from the
beginning:
How could we avoid WAL logging for INSERT ... SELECT?
The way we do it for CREATE TABLE AS is because nobody would even *see*
the table if our transaction doesn't commit. Therefore we don't need to
bother logging it. Same can be said for SELECT INTO.
INSERT ... SELECT is just an insert. It needs just as much logging as
inserting tuples any other way. For instance, it will potentially share
pages with other inserts, and better properly record all such page
modifications so that they return to a consistent state.
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2011-08-05 00:55:47 | Re: Reduce WAL logging of INSERT SELECT |
Previous Message | Alex Hunsaker | 2011-08-05 00:44:18 | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https |