From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
---|---|
To: | Andy Colson <andy(at)squeakycode(dot)net> |
Cc: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, PostgreSQL <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: general questions postgresql performance config |
Date: | 2010-01-26 22:22:17 |
Message-ID: | 4B5F6B19.3090804@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Andy Colson wrote:
> I recall seeing someplace that you can avoid WAL if you start a
> transaction, then truncate the table, then start a COPY.
>
> Is that correct? Still hold true? Would it make a lot of difference?
That is correct, still true, and can make a moderate amount of
difference if the WAL is really your bottleneck. More of a tweak for
loading small to medium size things as I see it. Once the database and
possibly its indexes get large enough, the loading time starts being
dominated by handling all that work, with its random I/O, rather than
being limited by the sequential writes to the WAL. It's certainly a
useful optimization to take advantage of when you can, given that it's
as easy as:
BEGIN;
TRUNCATE TABLE x;
COPY x FROM ... ;
COMMIT;
--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com
From | Date | Subject | |
---|---|---|---|
Next Message | steeles | 2010-01-26 22:28:56 | Re: pg dump.. issue with when using crontab |
Previous Message | Greg Smith | 2010-01-26 22:12:51 | Re: 100% of CPU utilization postgres process |