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

Re: Sync Scan update

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Jeff Davis" <pgsql(at)j-davis(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>,"Luke Lonergan" <llonergan(at)greenplum(dot)com>
Subject: Re: Sync Scan update
Date: 2006-12-19 17:43:58
Message-ID: 1166550238.3654.280.camel@silverbirch.site (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, 2006-12-19 at 09:07 -0800, Jeff Davis wrote:
> I have updated my Synchronized Scan patch and have had more time for
> testing.
> 
> Go to http://j-davis.com/postgresql/syncscan-results10.html
> where you can download the patch, and see the benchmarks that I've run.
> 
> The results are very promising. I did not see any significant slowdown
> for non-concurrent scans or for scans that fit into memory, although I
> do need more testing in this area.

Yes, very promising.

Like to see some tests with 2 parallel threads, since that is the most
common case. I'd also like to see some tests with varying queries,
rather than all use select count(*). My worry is that these tests all
progress along their scans at exactly the same rate, so are likely to
stay in touch. What happens when we have significantly more CPU work to
do on one scan - does it fall behind??

I'd like to see all testing use log_executor_stats=on for those
sessions. I would like to know whether the blocks are being hit while
still in shared_buffers or whether we rely on the use of the full
filesystem buffer cache to provide performance.

It would be very cool to run a background performance test also, say a
pgbench run with a -S 100. That would show us what its like to try to
run multiple queries when most of the cache is full with something else.

It would be better to have a GUC to control the scanning
e.g.
	synch_scan_threshold = 256MB

rather than link it to effective_cache_size always, since that is
related to index scan tuning.

-- 
  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com



In response to

Responses

pgsql-hackers by date

Next:From: Chris BrowneDate: 2006-12-19 17:55:12
Subject: Re: Autovacuum Improvements
Previous:From: Bruce MomjianDate: 2006-12-19 17:23:50
Subject: Release 8.2.0 done, 8.3 development starts

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