Horton

Re: Seq scans roadmap

Heikki Linnakangas <heikki@enterprisedb.com>

View thread View on postgr.es
From: Heikki Linnakangas <heikki@enterprisedb.com>
To: Simon Riggs <simon@enterprisedb.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, Zeugswetter Andreas ADI SD <ZeugswetterA@spardat.at>, CK Tan <cktan@greenplum.com>, Luke Lonergan <LLonergan@greenplum.com>, Jeff Davis <pgsql@j-davis.com>
Date: 2007-05-14T11:41:45Z
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