Re: Bug: Buffer cache is not scan resistant - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Bug: Buffer cache is not scan resistant
Date
Msg-id 20896.1173120946@sss.pgh.pa.us
Whole thread Raw
In response to Re: Bug: Buffer cache is not scan resistant  ("Pavan Deolasee" <pavan@enterprisedb.com>)
List pgsql-hackers
"Pavan Deolasee" <pavan@enterprisedb.com> writes:
> I am wondering whether seqscan would set the usage_count to 1 or to a higher
> value. usage_count is  incremented while unpinning the buffer. Even if 
> we use
> page-at-a-time mode, won't the buffer itself would get pinned/unpinned
> every time seqscan returns a tuple ? If thats the case, the overhead would
> be O(BM_MAX_USAGE_COUNT * N) for every N reads.

No, it's only once per page.  There's a good deal of PrivateRefCount
thrashing that goes on while examining the individual tuples, but the
shared state only changes when we leave the page, because we hold pin
continuously on the current page of a seqscan.  If you don't believe
me, insert some debug printouts for yourself.

> How about smaller value for BM_MAX_USAGE_COUNT ?

This is not relevant to the problem: we are concerned about usage count
1 versus 0, not the other end of the range.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Pavan Deolasee"
Date:
Subject: Re: Bug: Buffer cache is not scan resistant
Next
From: Gregory Stark
Date:
Subject: Re: Bug: Buffer cache is not scan resistant