Thread added to TODO for item:
* Allow sequential scans to take advantage of other concurrent
sequential scans, also called Synchronised Scanning
---
Jeff Davis wrote:
I have updated my Synchronized Scan patch and have
On Sat, 2006-12-30 at 13:35 -0600, Jim C. Nasby wrote:
My current implementation relies on the scans to stay close together
once they start close together. If one falls seriously behind, it will
fall outside of the main cache trail and cause the performance to
degrade due to disk seeking
On Tue, Jan 02, 2007 at 09:48:22AM -0800, Jeff Davis wrote:
On Sat, 2006-12-30 at 13:35 -0600, Jim C. Nasby wrote:
My current implementation relies on the scans to stay close together
once they start close together. If one falls seriously behind, it will
fall outside of the main cache
On Tue, Dec 19, 2006 at 10:37:21AM -0800, Jeff Davis wrote:
leader is doing a nested loop and the follower which is just doing a
straight
sequential scan is being held back?
The follower will never be held back in my current implementation.
My current implementation relies on the
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
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
On Tue, 2006-12-19 at 17:43 +, Simon Riggs wrote:
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
Simon Riggs [EMAIL PROTECTED] writes:
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
On Tue, 2006-12-19 at 18:05 +, Gregory Stark wrote:
Simon Riggs [EMAIL PROTECTED] writes:
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
