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

Re: idea for concurrent seqscans

From: Jeff Davis <jdavis-pgsql(at)empires(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: idea for concurrent seqscans
Date: 2005-02-26 08:22:45
Message-ID: 1109406165.4089.205.camel@jeff (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
I have a newer version of my Synchronized Scanning patch which hopefully
makes it closer to a real patch, the first one was more of a proof of

* I added a proper bounds check for the result it gets from shared
* I expanded the shared memory to be a static hash table (currently set
to a size of 8KB, but that is a one line change if that's too big). Now
it can keep track of many scans on many tables at once.

* More testing. I plan to get some more tests up on Monday, and when I
start to see the best uses for this patch, I will also try to benchmark
against MySQL or something else. I'm seeing some good preliminary
results in cache hit rate (which is much higher in some cases), but I
need to demonstrate an actual decrease in runtime.
* Right now the shared mem isn't destroyed when the postmaster shuts
* This patch still makes no use of locks at all. If someone thinks locks
are required, please let me know. Currently, if there is inconsistent
data in the shared memory area the worst that can happen is no worse
than the current behavior.

	Jeff Davis

Attachment: heapam.c.diff
Description: text/x-patch (15.9 KB)
Attachment: heapam.h.diff
Description: text/x-patch (779 bytes)
Attachment: relscan.h.diff
Description: text/x-patch (455 bytes)

In response to


pgsql-hackers by date

Next:From: William VolkmanDate: 2005-02-26 10:28:09
Subject: Re: idea for concurrent seqscans
Previous:From: Chris TraversDate: 2005-02-26 05:50:02
Subject: Re: Development Plans

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