Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> I just ran a quick test with 4 concurrent scans on a dual-core system,
> and it looks like we do "leak" buffers from the rings because they're
> pinned at the time they would be recycled.
Yeah, I noticed the same in some tests here. I think there's not a lot
we can do about that; we don't have enough visibility into why someone
else has the buffer pinned.
Using a larger ring would help, by making it less probable that any
other sync-scanning backend is so far behind as to still have the oldest
element of our ring pinned. But if we do that we have the L2-cache-size
effect to worry about. Is there any actual data backing up that it's
useful to keep the ring fitting in L2, or is that just guesswork? In
the sync-scan case the idea seems pretty bogus anyway, because the
actual working set will be N backends' rings not just one.
regards, tom lane
In response to
pgsql-patches by date
|Next:||From: Bruce Momjian||Date: 2007-05-30 19:59:17|
|Subject: Re: OS X startup script patch|
|Previous:||From: Bruce Momjian||Date: 2007-05-30 19:50:42|
|Subject: Re: COPY-able csv log outputs|