Re: concurrent COPY performance - Mailing list pgsql-hackers

From Gurjeet Singh
Subject Re: concurrent COPY performance
Date
Msg-id 65937bea0906191350q74408e1dx5ad5884158cf8a04@mail.gmail.com
Whole thread Raw
In response to Re: concurrent COPY performance  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-hackers
On Wed, Jun 17, 2009 at 3:44 AM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote:
Andrew Dunstan <andrew@dunslane.net> wrote:

> If a table is created or truncated in the same transaction that does
> the load, and archiving is not on, the COPY is not WALed.

Slightly off topic, but possibly relevant to the overall process:
those are the same conditions under which I would love to see the
rows inserted with the hint bits showing successful commit and the
transaction ID showing frozen.  We currently do a VACUUM FREEZE
ANALYZE after such a load, to avoid burdening random users with the
writes.  It would be nice not to have to write all the pages again
right after a load.

+1 (if it is doable, that is).

Best regards,
--
Lets call it Postgres

EnterpriseDB      http://www.enterprisedb.com

gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | indiatimes | yahoo }.com
Mail sent from my BlackLaptop device

pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: Suppressing occasional failures in copy2 regression test
Next
From: Merlin Moncure
Date:
Subject: cassert: array size exceeds the maximum allowed (134217727)