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

Synchronized Scan benchmark results

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: simon(at)2ndquadrant(dot)com
Subject: Synchronized Scan benchmark results
Date: 2007-04-02 23:14:35
Message-ID: 1175555675.13696.29.camel@dogma.v10.wvs (view raw or flat)
Thread:
Lists: pgsql-hackers
I posted some fairly detailed benchmark results for my Synchronized Scan
patch and it's interactions with Simon Riggs' Recycle Buffers patch
here:

http://j-davis.com/postgresql/patch15-results.html

The results are in the form of log files that contain lots of useful
debugging info:

* log_executor_stats is on (meaning it shows cache hit rate)
* the pid, timestamp, and pagenumber being retrieved (for every 5k pages
read)
* the duration of each scan

The results are very positive and quite conclusive.

However, the "sync_seqscan_offset" aspect of my patch, which attempts to
use pages that were cached before the scan began, did not show a lot of
promise. That aspect of my patch may end up being cut.

The primary aspect of my patch, the Synchronized Scanning, performed
great though. Even the CFQ scheduler, that does not appear to properly
read ahead, performed substantially better than plain 8.2.3. And even
better, Simon's patch didn't seem to hurt Synchronized Scans at all.

Out of the 36 runs I did, a couple appear anomalous. I will retest those
soon.

Note: I posted the versions of the patches that I used for the tests on
the page above. The version of Simon's patch that I used did not apply
cleanly to 8.2.3, but the only problem appeared to be in copy.c, so I
went ahead with the tests. If this somehow compromised the patch, then
let me know.

Regards,
	Jeff Davis




Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2007-04-02 23:15:44
Subject: Re: Bug: Buffer cache is not scan resistant
Previous:From: Mark DilgerDate: 2007-04-02 23:11:57
Subject: Re: Bug in UTF8-Validation Code?

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