Re: less expensive pg_buffercache on big shmem

Поиск
Список
Период
Сортировка
От Ivan Kartyshov
Тема Re: less expensive pg_buffercache on big shmem
Дата
Msg-id 62b5173f-a0fd-c2d7-2cce-c888b99fd098@postgrespro.ru
обсуждение исходный текст
Ответ на Re: less expensive pg_buffercache on big shmem  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: less expensive pg_buffercache on big shmem  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
On 09/03/2016 05:04 AM, Tomas Vondra wrote:> This patch needs a rebase, as 06d7fd6e bumped the version to 1.2.
Thank you for a valuable hint.
> > 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
fullyup to its name, though)>> In other words, it does exactly the thing proposed up-thread, i.e.> locking only buffer
headers.>>What do you mean by fast spinlocks? And why aren't they up to the name?
 

Not they (spinlocks), but the name “nonconsistent” is somewhat 
misleading. At the moment we can't implement concurrent shared memory 
access without locks in general, so most inconsistent method that has 
been proposed was the "nonconsistent" one. But roughly speaking 
*nonconsistent* is not as such by the name, because it contains a 
locking mechanism (spinlocks).
> > 2) it's *almost* the fastest one (the less time needed for execution of> > method, the less data core will change
andas a consequence the more> > consistent snapshot will be)>> I'm not sure I understand what you're saying here? What
doyou mean by> "almost the fastest one"?
 

I mean the fastest one that has been proposed ("consistent"| 
"semiconsistent"| "nonconsistent").
> I'm a bit confused by the results you reported before, i.e. that>> 1) nonconsistent is 10% faster than consistent
method>2) semiconsistent is 5-times slower than nonconsistent method>> What does that mean? Are you refering to
durationof the queries reading> data from pg_buffercache, or to impact on the other queries?
 

Here I mean "working duration time".
> How can be semiconsistent 5x slower than nonconsistent? Wouldn't that> make it significantly slower than the
consistentmethod?
 

Firstly, when we want to measure the quality of pg_buffercache, we must 
measure several values:
1) Execution time (duration of the queries reading data from pg_buffercache)
2) How it influences the system (and other queries) during its work

Secondly, the semiconsistent is slower than nonconsistent and consistent 
method, but it makes less influence on other queries then consistent.

Thirdly, it is slower because it locks the partitions of shared memory 
in a different way than in consistent or nonconsistent methods.
The semi-consistent strategy implies that only one buffer is locked at a 
time. Therefor has no significant effect on the system, but it takes 
more time.


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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Better locale-specific-character-class handling for regexps
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Supporting SJIS as a database encoding