Re: Global shared meta cache

Поиск
Список
Период
Сортировка
От AJG
Тема Re: Global shared meta cache
Дата
Msg-id 1530037256720-0.post@n3.nabble.com
обсуждение исходный текст
Ответ на Global shared meta cache  ("Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>)
Ответы RE: Global shared meta cache  ("Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>)
Список pgsql-hackers
Ideriha, Takeshi wrote
> 2) benchmarked 3 times for each conditions and got the average result of
> TPS.
>                                      |master branch | prototype      |
> proto/master (%)
>   
> ------------------------------------------------------------------------------------
>    pgbench -c48 -T60 -Msimple -S   | 131297       |130541       |101%
>    pgbench -c48 -T60 -Msimple      | 4956          |4965       |95%
>    pgbench -c48 -T60 -Mprepared -S |129688       |132538       |97%
>    pgbench -c48 -T60 -Mprepared    |5113       |4615       |84%
> 
> 
> 001_global_meta_cache.patch (6K)
> <http://www.postgresql-archive.org/attachment/6026686/0/001_global_meta_cache.patch>


Hello,
Apologies for question. I thought I would just double check percentages that
have been presented.
Is the percentage calculation correct?
as #1 and #3 look inverted to me (say lower when should be higher and vice
versa), and 
#2 and #4 look incorrect generally (percentages look much larger than they
should be based on numbers.

I.e. Msimple -S the protype had slightly worse tps performance (130541)
versus Master (131297). I would expect the percentage to be e.g. 99% not
101%

But I may be misunderstanding something :)

Also, Msimple is 4956 master versus 4965 prototype. Just 9 tps change. A
very slight improvement in tps. but the percentage provided is 95%. I would
expect it to be just over 100%?
Again, maybe im not understanding, and hoping it is just my error :)



--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html


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

Предыдущее
От: Rushabh Lathia
Дата:
Сообщение: wrong query result with jit_above_cost= 0
Следующее
От: Andres Freund
Дата:
Сообщение: Re: wrong query result with jit_above_cost= 0