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