From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
Cc: | Zeugswetter Andreas ADI SD <ZeugswetterA(at)spardat(dot)at>, CK Tan <cktan(at)greenplum(dot)com>, Luke Lonergan <LLonergan(at)greenplum(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jeff Davis <pgsql(at)j-davis(dot)com>, Simon Riggs <simon(at)enterprisedb(dot)com> |
Subject: | Re: Seq scans roadmap |
Date: | 2007-05-10 17:33:28 |
Message-ID: | 46435768.9020909@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-05-10 18:02:37 | Re: Seq scans roadmap |
Previous Message | Sven Janson | 2007-05-10 15:58:38 | Question concerning failed installation of Postgres 8.2.3 on Windows XP |