Re: idea for concurrent seqscans

Thanks for the information.

On Sat, 2005-02-26 at 23:39 +1100, Neil Conway wrote:
> Jeff Davis wrote:
> > 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.
>
> A few minor comments:
>
> - context diffs (diff -c) are the preferred format. Also, folks usually
> send patches as a single diff; an easy way to generate that is via `cvs
> diff', or `diff -r old_dir new_dir'.

Ok.

> - needlessly reindenting code makes it difficult to understand what
> you've changed. You should probably follow the PG coding conventions WRT
> indentation, brace placement, and so forth, although this will be fixed
> by a script later in any case. See Chapter 43 of the docs.
>

The only reason I did that was because the original source was difficult
to read and work on. Is there a reason that code and comments wrap
around to the next line throughout the file?

> - PG has an abstraction layer for using shared memory that you should
> take advantage of. You should do something like: (1) create a function
> that returns the amount of shared memory space you require (2) invoke
> the function from CreateSharedMemoryAndSemaphores (3) create/attach to
> and initialize the shared memory during startup, via ShmemInitStruct().
> See how InitProcGlobal() works, for example.

Will do.

> - it makes me quite nervous to be reading and writing to shared data
> without using locks. If there is too much of a performance hit to
> acquire and release a lock for each page traversed, what about only
> updating the shared memory stats every K pages?
>

I'll try that and test it and hopefully any performance problems appear
sooner rather than later. If something appears, every K pages sounds
like a plan to me.

I will get a new patch ready soon with your suggestions.

Regards,
Jeff Davis