| From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)enterprisedb(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Zeugswetter Andreas ADI SD <ZeugswetterA(at)spardat(dot)at>, CK Tan <cktan(at)greenplum(dot)com>, Luke Lonergan <LLonergan(at)greenplum(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com> |
| Subject: | Re: Seq scans roadmap |
| Date: | 2007-05-14 11:41:45 |
| Message-ID: | 46484AF9.9090106@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon Riggs wrote:
> On Fri, 2007-05-11 at 22:59 +0100, Heikki Linnakangas wrote:
>> For comparison, here's the test results with vanilla CVS HEAD:
>>
>> copy-head | 00:06:21.533137
>> copy-head | 00:05:54.141285
>
> I'm slightly worried that the results for COPY aren't anywhere near as
> good as the SELECT and VACUUM results. It isn't clear from those numbers
> that the benefit really is significant.
Agreed, the benefit isn't clear.
> Are you thinking that having COPY avoid cache spoiling is a benefit just
> of itself? Or do you see a pattern of benefit from your other runs?
I think it's worth having just to avoid cache spoiling. I wouldn't
bother otherwise, but since we have the infrastructure for vacuum and
large seqscans, we might as well use it for COPY as well.
> (BTW what was wal_buffers set to? At least twice the ring buffer size,
> hopefully).
Good question. [checks]. wal_buffers was set to 128KB. I tried raising
it to 1MB, but it didn't make any difference.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Page | 2007-05-14 11:46:45 | Re: What is happening on buildfarm member baiji? |
| Previous Message | Zdenek Kotala | 2007-05-14 11:12:49 | Re: Performance monitoring |