| 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 01:23:27 |
| Message-ID: | 1312507407.22737.10.camel@jdavis-ux.asterdata.local |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2011-08-04 at 20:55 -0400, Bruce Momjian wrote:
> It would act like COPY, meaning the table would have to be truncated or
> created in the same transaction.
Well, in that case it could work for any INSERT. No need for a SELECT to
be involved. For that matter, why not make it work for DELETE and
UPDATE, too?
However, I think this is all just a workaround for not having a faster
loading path. I don't object to applying this optimization to inserts,
but I think it might be more productive to figure out if we can support
loading data efficiently -- i.e. also set hint bits and frozenxid during
the load.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2011-08-05 01:40:57 | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https |
| Previous Message | Robert Haas | 2011-08-05 01:14:40 | Re: Reduce WAL logging of INSERT SELECT |