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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
