From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, 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-06 10:13:58 |
Message-ID: | CA+U5nMKH2bAwUdvuuoC8dg7omsihgxsEa5gq_6UKLr06XH8aDQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Aug 6, 2011 at 4:16 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Well, if the table is created in the same transaction (which is the only
> case under consideration), no other sessions can write to the table so
> you are just writing the entire table on commit, rather than to the WAL.
Below a certain point, skipping WAL is slower and over an intermediate
range there is no benefit. So small amounts of data on large servers
goes slower.
heap_fsync() requires a scan of shared buffers, which may not be cheap.
There is a difficulty because you would need to calculate the cut-off
is for a particular database, and then predict ahead of time whether
the number of rows that will be handled by the statement is low enough
to warrant using the optimisation. Both of which I call a hard
problem.
I think we should remove the COPY optimisation because of this and
definitely not extend INSERT SELECT to perform it automatically.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2011-08-06 11:58:53 | Re: cataloguing NOT NULL constraints |
Previous Message | Peter Eisentraut | 2011-08-06 10:03:41 | Re: cataloguing NOT NULL constraints |