| From: | Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: concurrent COPY performance |
| Date: | 2009-06-19 20:50:55 |
| Message-ID: | 65937bea0906191350q74408e1dx5ad5884158cf8a04@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jun 17, 2009 at 3:44 AM, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov
> wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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[(dot)singh](at)EnterpriseDB(dot)com
singh(dot)gurjeet(at){ gmail | hotmail | indiatimes | yahoo }.com
Mail sent from my BlackLaptop device
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2009-06-19 21:27:53 | cassert: array size exceeds the maximum allowed (134217727) |
| Previous Message | Gurjeet Singh | 2009-06-19 20:47:43 | Re: Suppressing occasional failures in copy2 regression test |