Re: concurrent Postgres on NUMA - howto ? - Mailing list pgsql-hackers

Tom:  Notice that WriteBuffer would just put the fresh copy of the page
out in the shared space.  Other backends would get the latest  copy of the page when
THEY execute BufferAlloc() afterwards. [Remember, backends would
not have a local buffer cache, only (temporary) copies of one buffer
per BufferAlloc()/release pair].  [Granted about the bandwidth needs. In my target arch,
access to shmem is costlier and local mem, and cannot be done
via pointers (so a lot of code that might have pointers inside the
shmem buffer may need to be tracked down & changed)].  My idea is to use high-bandwidth access  via the
copy-in/copy-out
approach (hopefully pay only once that round-trip cost once per pair
BufferAlloc -> make buffer dirty].

[Mhy reasoning for this is that a backend needs to have exclusive
access to a buffer when it writes to it. And I think it 'advertises'
the new buffer contents to the world when it sets the BM_DIRTY flag.]
  About your suggestion of LockBuffer as synchronization points -
a simple protocol might be:          - copy 'in' the buffer on a READ. SHARE  or lock acquire             (may have to
becareful on an upgrade of a READ to a               write lock)   - copy 'out' the buffer on a WRITE lock release  I
wouldappreciate comments and input on this approach, as I
 
foresee putting a lot of effort into it soon,        regards                  Mauricio


>From: Tom Lane <tgl@sss.pgh.pa.us>
>To: "Mauricio Breternitz" <mbjsql@hotmail.com>
>CC: pgsql-hackers@postgresql.org
>Subject: Re: [HACKERS] concurrent Postgres on NUMA - howto ?
>Date: Mon, 23 Apr 2001 19:43:05 -0400
>
>"Mauricio Breternitz" <mbjsql@hotmail.com> writes:
> >     My concern is whether that is enough to maintain consistency
> > in the buffer cache
>
>No, it isn't --- for one thing, WriteBuffer wouldn't cause other
>backends to update their copies of the page.  At the very least you'd
>need to synchronize where the LockBuffer calls are, not where
>WriteBuffer is called.
>
>I really question whether you want to do anything like this at all.
>Seems like accessing the shared buffers right where they are will be
>fastest; your approach will entail a huge amount of extra data copying.
>Considering that a backend doesn't normally touch every byte on a page
>that it accesses, I wouldn't be surprised if full-page copying would
>net out to being more shared-memory traffic, rather than less.
>
>            regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/users-lounge/docs/faq.html

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com