Re: less expensive pg_buffercache on big shmem

On 09/02/2016 06:01 AM, Robert Haas wrote:
> I wonder whether we ought to just switch from the consistent method to
> the semiconsistent method and call it good.  I agree with you that
> taking every buffer partition lock simultaneously seems like too much
> locking.  And in the future if we replace the buffer mapping hash with
> something that is lock-free or close to it, then we wouldn't even have
> buffer partition locks any more, and probably no way at all to get an
> entirely consistent snapshot.
> What do you think of this?

I fully agree with you that it would be preferred in the future to 
replace the buffer mapping hash with some of lock-free algorithms.

In the question of replacing the consistent method I agree with you, 
Andres Freund and Peter Geoghegan: the consistent method does not bring 
any considerable benefits.

You might be right regarding the three different modes, but our DBAs 
asked if we could preserve a legacy mode too, thus the choice.

On 09/02/2016 06:19 AM, Andres Freund wrote: > +1. I think, before long, we're going to have to switch away from having
>locks & partitions in the first place. So I don't see a problem relaxing > this. It's not like that consistency really
buysyou anything...  I'd > even consider not using any locks.
 

If we will replace consistent method, then we should replace it with the 
partially consistent method (called "nonconsistent") because:
1) it's based on fast spinlocks (it's not fully up to its name, though)
2) it's *almost* the fastest one (the less time needed for execution of 
method, the less data core will change and as a consequence the more 
consistent snapshot will be)
3) and it has less influence on the entire system during query processing.

On 09/02/2016 06:30 AM, Peter Geoghegan wrote: > I would like to be able to run pg_buffercache in production from time
>to time.
 

Yes, in our experience the usage of fully consistent pg_buffercache in
production is quite a courageous decision.


---
Ivan Kartyshov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company