Skip site navigation (1) Skip section navigation (2)

Re: Seq scans status update

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Seq scans status update
Date: 2007-05-30 19:08:41
Message-ID: 1180552121.26915.149.camel@dogma.v10.wvs (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
On Tue, 2007-05-29 at 17:43 -0700, Jeff Davis wrote:
> > Hmm.  But we probably don't want the same buffer in two different
> > backends' rings, either.  You *sure* the sync-scan patch has no
> > interaction with this one?
> > 
> I will run some tests again tonight, I think the interaction needs more
> testing than I did originally. Also, I'm not sure that the hardware I
> have is sufficient to test those cases.

I ran some sanity tests last night with cvs head, plus my syncscan20-
cvshead.patch, plus scan_recycle_buffers.v3.patch.

It passed the sanity tests at least.

I did see that there was more interference with sync_seqscan_threshold=0
(always on) and scan_recycle_buffers=0 (off) than I had previously seen
with 8.2.4, so I will test again against 8.2.4 to see why that might be.
The interference that I saw was still quite small, a scan moving
concurrently with 9 other scans was about 10% slower than a scan running
alone -- which is still very good compared with plain cvs head and no
sync scan -- it's just not ideal. 

However, turning scan_recycle_buffers between 0 (off), 16, 32, and 128
didn't have much effect. At 32 it appeared to be about 1% worse during
10 scans, but that may have been noise. The other values I tried didn't
have any difference that I could see.

This was really just a quick sanity test, I think more hard data would
be useful.

	Jeff Davis

In response to


pgsql-patches by date

Next:From: Tom LaneDate: 2007-05-30 19:21:50
Subject: Re: Seq scans status update
Previous:From: Neil ConwayDate: 2007-05-30 19:02:04
Subject: Re: boolean <=> text explicit casts

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group