| From: | "Simon Riggs" <simon(at)enterprisedb(dot)com> |
|---|---|
| To: | "Heikki Linnakangas" <heikki(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-12 07:35:27 |
| Message-ID: | 1178955327.10861.394.camel@silverbirch.site |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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?
(BTW what was wal_buffers set to? At least twice the ring buffer size,
hopefully).
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Luke Lonergan | 2007-05-12 15:42:40 | Re: Seq scans roadmap |
| Previous Message | Tomas Doran | 2007-05-12 02:16:03 | Re: Implemented current_query |