From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: BufferAccessStrategy for bulk insert |
Date: | 2008-10-29 21:03:14 |
Message-ID: | 1225314194.3971.305.camel@ebony.2ndQuadrant |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2008-10-28 at 23:45 -0400, Robert Haas wrote:
> One concern that I have about this approach is that the situation in
> which people are probably most concerned about COPY performance is
> restoring a dump. In that case, the COPY will be the only thing
> running, and using a BufferAccessStrategy is an anti-optimization. I
> don't think it's a very big effect (any testing anyone can do on real
> hardware rather than what I have would be appreciated) but I'm sort of
> unsold of optimizing for what I believe to be the less-common use
> case. If the consensus is to reverse course on this point I'm happy
> to rip those changes back out and resubmit; they are a relatively
> small proportion of the patch.
Having COPY use a BAS is mainly to ensure it doesn't swamp the cache.
Which is a gain in itself.
If you say its a loss you should publish timings to support that. Using
a BAS for VACUUM was a performance gain, not a loss.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2008-10-29 21:10:33 | Re: pre-MED |
Previous Message | Alvaro Herrera | 2008-10-29 20:51:02 | Re: Block-level CRC checks |