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 buys you 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