Re: Seq scans status update - Mailing list pgsql-patches

From Tom Lane
Subject Re: Seq scans status update
Date
Msg-id 17918.1180554998@sss.pgh.pa.us
Whole thread Raw
In response to Re: Seq scans status update  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Seq scans status update  (Jeff Davis <pgsql@j-davis.com>)
Re: Seq scans status update  (Heikki Linnakangas <heikki@enterprisedb.com>)
List pgsql-patches
Heikki Linnakangas <heikki@enterprisedb.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

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: COPY-able csv log outputs
Next
From: Bruce Momjian
Date:
Subject: Re: OS X startup script patch