RE: Protect syscache from bloating with negative cache entries - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Protect syscache from bloating with negative cache entries
Date
Msg-id 0A3221C70F24FB45833433255569204D1FBBC085@G01JPEXMBYT05
Whole thread Raw
In response to RE: Protect syscache from bloating with negative cache entries  ("Ideriha, Takeshi" <ideriha.takeshi@jp.fujitsu.com>)
Responses RE: Protect syscache from bloating with negative cache entries
List 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 by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: FETCH FIRST clause PERCENT option
Next
From: Chapman Flack
Date:
Subject: Re: proposal: variadic argument support for least, greatest function