Re: idea for concurrent seqscans - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: idea for concurrent seqscans
Date
Msg-id 1109406165.4089.205.camel@jeff
Whole thread Raw
In response to idea for concurrent seqscans  (Jeff Davis <jdavis-pgsql@empires.org>)
Responses Re: idea for concurrent seqscans  (Neil Conway <neilc@samurai.com>)
Re: idea for concurrent seqscans  ("Jim C. Nasby" <decibel@decibel.org>)
List 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
concept.

DONE:
* I added a proper bounds check for the result it gets from shared
memory.
* 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.

TODO:
* 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
down.
* 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.

Regards,
    Jeff Davis

Attachment

pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: idea for concurrent seqscans
Next
From: William Volkman
Date:
Subject: Re: idea for concurrent seqscans