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

From Jim C. Nasby
Subject Re: idea for concurrent seqscans
Date
Msg-id 20050226161627.GY84483@decibel.org
Whole thread Raw
In response to Re: idea for concurrent seqscans  (Jeff Davis <jdavis-pgsql@empires.org>)
Responses Re: idea for concurrent seqscans  (Jeff Davis <jdavis-pgsql@empires.org>)
List pgsql-hackers
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@decibel.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?"


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: idea for concurrent seqscans
Next
From: Tom Lane
Date:
Subject: Re: Development Plans