| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | 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:46:35 |
| Message-ID: | 201108042146.p74LkZX21818@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andrew Dunstan wrote:
>
>
> On 08/04/2011 04:55 PM, Tom Lane wrote:
> > Bruce Momjian<bruce(at)momjian(dot)us> writes:
> >> One thing we don't optimize is INSERT ... SELECT when the table is
> >> created or truncated in the same transaction. Seems we could.
> >> We optimize CREATE TABLE AS which is effectively SELECT ... INTO using a
> >> different syntax. Is this a TODO?
> > Considering that SELECT INTO is deprecated, I don't think we should be
> > expending effort to encourage people to use it.
> >
> >
>
>
> Right, but the original point about INSERT ... SELECT seems reasonable, no?
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.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2011-08-04 21:59:24 | Re: Reduce WAL logging of INSERT SELECT |
| Previous Message | Tom Lane | 2011-08-04 21:26:49 | Re: error: could not find pg_class tuple for index 2662 |