Re: Seq scans roadmap - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Seq scans roadmap
Date
Msg-id 46435768.9020909@enterprisedb.com
Whole thread Raw
In response to Re: Seq scans roadmap  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Seq scans roadmap  (Heikki Linnakangas <heikki@enterprisedb.com>)
List pgsql-hackers
Heikki Linnakangas wrote:
> However, it caught me by total surprise that the performance with 1 
> buffer is so horrible. Using 2 buffers is enough to avoid whatever the 
> issue is with just 1 buffer. I have no idea what's causing that. There 
> must be some interaction that I don't understand.

Ok, I found the reason for that. I was using this query for the selects:
SELECT COUNT(*) FROM (SELECT 1 FROM stock_copytest LIMIT 10000000) AS a;

Stock_copytest is larger than RAM size, that's why I used the LIMIT to 
make the result set memory resident. That had the side effect that 
apparently the limit-node kept the single buffer pinned which defeated 
the buffer ring completely. To avoid issues like that we apparently want 
to use 2-4 buffers instead of just 1.

I'll review my test methodology and keep testing...

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Sven Janson
Date:
Subject: Question concerning failed installation of Postgres 8.2.3 on Windows XP
Next
From: "CK Tan"
Date:
Subject: Re: Seq scans roadmap