Re: Seq scans status update

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