Re: idea for concurrent seqscans

On Sat, 2005-02-26 at 10:16 -0600, Jim C. Nasby wrote:
> 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?
>

I don't know if we want to clutter the GUC variables with a bunch of
minor things like this. Most users won't understand what they're
actually getting by allocating more memory here. The only improvement
would be if there are two tables that are very often scanned
simultaneously that happen to hash to the same value, in which case
decreasing the shared mem has almost as much chance of solving the
problem as increasing it :)

However, if people think it's worthwhile, I'll be happy to do it.

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

Good idea. However, the first scan on a table after a server start will
always be default, so I'll need to avoid excessive logging.

Regards,
Jeff Davis