On Tue, 2007-01-09 at 16:31 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
...continuing this discussion about setting HEAP_XMIN_COMMITTED...
BTW, a sufficient counterexample for that kluge is that neither SPI or
SQL-function execution use a separate portal for invoked
Simon Riggs [EMAIL PROTECTED] writes:
I agree we could get this to Just Work by altering
HeapTupleSatisfies...() functions so that their first test is
if (TransactionIdIsCurrentTransactionId(xvac))
rather then
if (!(tuple-t_infomask HEAP_XMIN_COMMITTED))
Huh? That doesn't make
On Wed, 2007-01-10 at 10:37 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I agree we could get this to Just Work by altering
HeapTupleSatisfies...() functions so that their first test is
if (TransactionIdIsCurrentTransactionId(xvac))
Oh? Sorry, I meant xmin not xvac at
On Sat, Jan 06, 2007 at 09:20:53PM -0500, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Reason for no documentation was that CREATE INDEX and CREATE TABLE AS
SELECT already use this optimisation, but to my knowledge neither was/is
documented on those command
On Sun, 2007-01-07 at 11:29 -0500, Tom Lane wrote:
I wrote:
... The active-portal kluge that you've just
mentioned is nothing but a kluge, proving that you thought of some cases
where it would fail. But I doubt you thought of everything.
New patch submitted to -patches on different
On Sat, 2007-01-06 at 21:32 -0500, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
On Saturday 06 January 2007 16:36, Simon Riggs wrote:
snip
BEGIN;
CREATE TABLE foo...
INSERT INTO foo--uses WAL
COPY foo.. --no WAL
INSERT INTO foo--uses WAL
COPY foo.. --no WAL
On Sat, 2007-01-06 at 21:18 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The rule is: if the relfilenode for a table is new in this transaction
(and therefore the whole things will be dropped at end-of-transaction)
then *all* COPY commands are able to avoid writing WAL
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2007-01-06 at 21:18 -0500, Tom Lane wrote:
Uh ... what in the world has an active portal got to do with it?
I think you've confused snapshot considerations with crash recovery.
The patch sets HEAP_XMIN_COMMITTED on all of the rows loaded by COPY
On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Sat, 2007-01-06 at 21:18 -0500, Tom Lane wrote:
Uh ... what in the world has an active portal got to do with it?
I think you've confused snapshot considerations with crash recovery.
The patch
On Sun, Jan 07, 2007 at 11:46:29AM +, Simon Riggs wrote:
On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The patch sets HEAP_XMIN_COMMITTED on all of the rows loaded by COPY as
well.
I think you just talked yourself out of getting this
On Sun, 2007-01-07 at 12:59 +0100, Martijn van Oosterhout wrote:
On Sun, Jan 07, 2007 at 11:46:29AM +, Simon Riggs wrote:
On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
The patch sets HEAP_XMIN_COMMITTED on all of the rows loaded by COPY as
Simon Riggs [EMAIL PROTECTED] writes:
On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
I think you just talked yourself out of getting this patch applied.
Maybe; what would be your explanation?
The main reason is that you were guilty of false advertising. This
patch was described as being
I wrote:
... The active-portal kluge that you've just
mentioned is nothing but a kluge, proving that you thought of some cases
where it would fail. But I doubt you thought of everything.
BTW, a sufficient counterexample for that kluge is that neither SPI or
SQL-function execution use a
On Sun, 2007-01-07 at 11:14 -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Sun, 2007-01-07 at 03:53 -0500, Tom Lane wrote:
I think you just talked yourself out of getting this patch applied.
Maybe; what would be your explanation?
The main reason is that you were guilty
On Sun, 2007-01-07 at 11:29 -0500, Tom Lane wrote:
I wrote:
... The active-portal kluge that you've just
mentioned is nothing but a kluge, proving that you thought of some cases
where it would fail. But I doubt you thought of everything.
BTW, a sufficient counterexample for that kluge
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, I am going need to add documentation in the COPY manual page or no
one will know about this performance enhancement.
I don't think it belongs in COPY. What would make more sense is another
item under the populating a database performance tips,
Euler Taveira de Oliveira [EMAIL PROTECTED] writes:
Simon Riggs wrote:
The enclosed patch implements this, as discussed. There is no user
interface to enable/disable, just as with CTAS and CREATE INDEX; no
docs, just code comments.
IMHO, this deserves an GUC parameter (use_wal_in_copy?).
Simon Riggs [EMAIL PROTECTED] writes:
The rule is: if the relfilenode for a table is new in this transaction
(and therefore the whole things will be dropped at end-of-transaction)
then *all* COPY commands are able to avoid writing WAL safely, if:
- PITR is not enabled
- there is no active
Bruce Momjian [EMAIL PROTECTED] writes:
Simon Riggs wrote:
Reason for no documentation was that CREATE INDEX and CREATE TABLE AS
SELECT already use this optimisation, but to my knowledge neither was/is
documented on those command pages.
I wasn't aware those used the optimization. Seems they
Robert Treat [EMAIL PROTECTED] writes:
On Saturday 06 January 2007 16:36, Simon Riggs wrote:
snip
BEGIN;
CREATE TABLE foo...
INSERT INTO foo --uses WAL
COPY foo.. --no WAL
INSERT INTO foo --uses WAL
COPY foo.. --no WAL
INSERT INTO foo --uses WAL
COPY foo... --no WAL
Is there some technical reason that the INSERT statements need to use WAL
in
these scenarios?
First, there's enough other overhead to an INSERT that you'd not save
much percentagewise. Second, not using WAL doesn't come for free: the
cost is having to fsync the whole table
Joshua D. Drake [EMAIL PROTECTED] writes:
cost is having to fsync the whole table afterwards. So it really only
makes sense for commands that one can expect are writing pretty much
all of the table. I could easily see it being a net loss for individual
INSERTs.
What about multi value
On Sat, 2007-01-06 at 22:09 -0500, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
cost is having to fsync the whole table afterwards. So it really only
makes sense for commands that one can expect are writing pretty much
all of the table. I could easily see it being a net loss
23 matches
Mail list logo