Re: Seq scans status update
От | Jeff Davis |
---|---|
Тема | Re: Seq scans status update |
Дата | |
Msg-id | 1180552121.26915.149.camel@dogma.v10.wvs обсуждение исходный текст |
Ответ на | Re: Seq scans status update (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Seq scans status update
|
Список | 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. Regards, Jeff Davis
В списке pgsql-patches по дате отправления: