Re: idea for concurrent seqscans

On Sat, Feb 26, 2005 at 12:22:45AM -0800, Jeff Davis wrote:
> * 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.

I know you're still early in this, but should this value be a GUC?

> * 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.

It would be useful to have the backend put something in the logfile any
time it has to revert to the default behavior. Without that, we have no
way to know how often it's happening, and if it's worth trying to make
it happen less.
--
Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"