From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Jeff Davis" <pgsql(at)j-davis(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Synchronized Scan update |
Date: | 2007-03-12 15:42:40 |
Message-ID: | C21AC300.29181%llonergan@greenplum.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon,
On 3/12/07 6:21 AM, "Simon Riggs" <simon(at)2ndquadrant(dot)com> wrote:
> So based on those thoughts, sync_scan_offset should be fixed at 16,
> rather than being variable. In addition, ss_report_loc() should only
> report its position every 16 blocks, rather than do this every time,
> which will reduce overhead of this call.
And for N concurrent scans?
I think there is actually no need to synchronize the shared buffers at all
for synchronized scans. The OS I/O cache will do that for us and we're just
going to interfere and pessimize by trying to divide up a local buffer.
I suggest that this be proven or disproved by running this test: measure the
performance of syncscan with the non-polluting buffer change, then measure
with Jeff's patch and non-polluting with multiple scans, then measure with
your suggested changes to synchronize the buffers.
Somewhere in that progression we'll learn more about how the multi-level
buffering really works. I think we'll get all the shared I/O cache we need.
- Luke
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-03-12 16:24:13 | Re: Synchronized Scan update |
Previous Message | Andrew Dunstan | 2007-03-12 15:22:24 | Re: Updating large postgresql database with blobs |