From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: evtcache: EventTriggerCache vs Event Trigger Cache |
Date: | 2023-05-08 08:39:42 |
Message-ID: | AB135621-B256-4AB5-A9B8-021A47FE643D@yesql.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On 4 May 2023, at 14:18, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
>> On 4 May 2023, at 14:09, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
>>> When reading a memory contexts log I realized that we have this:
>>> LOG: level: 2; EventTriggerCache: 8192 total in 1 blocks; 7928 free (4 chunks); 264 used
>>> LOG: level: 3; Event Trigger Cache: 8192 total in 1 blocks; 2616 free (0 chunks); 5576 used
>>
>>> The reason is that BuildEventTriggerCache sets up a context "EventTriggerCache"
>>> which house a hash named "Event Trigger Cache" which in turn creates a context
>>> with the table name. I think it makes sense that these share the same name,
>>> but I think it would be less confusing if they also shared the same spelling
>>> whitespace-wise. Any reason to not rename the hash EventTriggerCache to make
>>> the logging a tiny bit easier to read and grep?
>>
>> Hmm, I'm kinda -1 on them having the same name visible in the
>> contexts dump --- that seems very confusing. How about naming
>> the hash "EventTriggerCacheHash" or so?
>
> I think the level is the indicator here, but I have no strong opinions,
> EventTriggerCacheHash is fine by me.
The attached trivial diff does that, parking this in the next CF.
--
Daniel Gustafsson
Attachment | Content-Type | Size |
---|---|---|
evtcachehash.diff | application/octet-stream | 550 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | John Naylor | 2023-05-08 10:23:23 | Re: [PoC] Improve dead tuple storage for lazy vacuum |
Previous Message | Masahiko Sawada | 2023-05-08 08:21:18 | Re: [DOC] Update ALTER SUBSCRIPTION documentation |