On Jun 9, 2011, at 9:28 AM, Robert Haas wrote: > On Thu, Jun 9, 2011 at 10:22 AM, Alvaro Herrera > <alvhe...@commandprompt.com> wrote: >>> 1. Subdivide XLOG insertion into three operations: (1) allocate space >>> in the log buffer, (2) copy the log records into the allocated space, >>> and (3) release the space to the buffer manager for eventual write to >>> disk. AIUI, WALInsertLock currently covers all three phases of this >>> operation, but phase 2 can proceed in parallel. It's pretty easy to >>> imagine maintain one pointer that references the next available byte >>> of log space (let's call this the "next insert" pointer), and a second >>> pointer that references the byte following the last byte known to be >>> written (let's call this the "insert done" pointer). >> >> I think this can be done more simply if instead of a single "insert >> done" pointer you have an array of them, one per backend; there's also a >> global pointer that can be advanced per the minimum of the bunch, which >> you can calculate with some quick locking of the array. You don't need >> to sleep at all, except to update the array and calculate the global >> ptr, so this is probably also faster. > > I think looping over an array with one entry per backend is going to > be intolerably slow... but it's possible I'm wrong.
If the global pointer is just tracking the minimum of the array entries, do you actually have to lock the entire array? The global pointer is going to be "behind" soon enough anyway, so why does it need a static view of the entire array? ISTM you only need to ensure that updating individual elements in the array is atomic. -- Jim C. Nasby, Database Architect j...@nasby.net 512.569.9461 (cell) http://jim.nasby.net -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
