Skip site navigation (1) Skip section navigation (2)

Re: idea for concurrent seqscans

From: Jeff Davis <jdavis-pgsql(at)empires(dot)org>
To: Neil Conway <neilc(at)samurai(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: idea for concurrent seqscans
Date: 2005-02-26 19:02:28
Message-ID: 1109444548.4089.244.camel@jeff (view raw or flat)
Thread:
Lists: pgsql-hackers
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


In response to

Responses

pgsql-hackers by date

Next:From: Jeff DavisDate: 2005-02-26 19:05:57
Subject: Re: idea for concurrent seqscans
Previous:From: Joshua D. DrakeDate: 2005-02-26 18:47:19
Subject: Re: Development schedule

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group