RE: Protect syscache from bloating with negative cache entries

Поиск
Список
Период
Сортировка
От Tsunakawa, Takayuki
Тема RE: Protect syscache from bloating with negative cache entries
Дата
Msg-id 0A3221C70F24FB45833433255569204D1FBBC085@G01JPEXMBYT05
обсуждение исходный текст
Ответ на RE: Protect syscache from bloating with negative cache entries  ("Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>)
Ответы RE: Protect syscache from bloating with negative cache entries
Список pgsql-hackers
From: Ideriha, Takeshi/出利葉 健
> [Size=800, iter=1,000,000]
> Master |15.763
> Patched|16.262 (+3%)
> 
> [Size=32768, iter=1,000,000]
> Master |61.3076
> Patched|62.9566 (+2%)

What's the unit, second or millisecond?
Why is the number of digits to the right of the decimal point?

Is the measurement correct?  I'm wondering because the difference is larger in the latter case.  Isn't the accounting
processingalmost the sane in both cases?
 
* former: 16.262 - 15.763 = 4.99
* latter: 62.956 - 61.307 = 16.49


> At least compared to previous HashAg version, the overhead is smaller.
> It has some overhead but is increase by 2 or 3% a little bit?

I think the overhead is sufficiently small.  It may get even smaller with a trivial tweak.

You added the new member usedspace at the end of MemoryContextData.  The original size of MemoryContextData is 72
bytes,and Intel Xeon's cache line is 64 bytes.  So, the new member will be on a separate cache line.  Try putting
usedspacebefore the name member.
 


Regards
Takayuki Tsunakawa


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

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: FETCH FIRST clause PERCENT option
Следующее
От: Chapman Flack
Дата:
Сообщение: Re: proposal: variadic argument support for least, greatest function