From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, cca5507 <cca5507(at)qq(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Redundant syscache access in get_rel_sync_entry() |
Date: | 2024-07-12 02:28:28 |
Message-ID: | 2247647.1720751308@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Thu, Jul 11, 2024 at 07:10:58PM +0530, Ashutosh Bapat wrote:
>> I think it's just convenient. We do that at multiple places; not exactly
>> these functions but functions which fetch relation attributes from cached
>> tuples. Given that the tuple is cached and local to the backend, it's not
>> too expensive. But if there are multiple places which do something like
>> this, we may want to create more function get_rel_* function which return
>> multiple properties in one function call. I see get_rel_namspace() and
>> get_rel_name() called together at many places.
> That's not worth the complications based on the level of caching.
> This code is fine as-is.
I could get behind creating such functions if there were a
demonstrable performance win, but in places that are not hot-spots
that's unlikely to be demonstrable.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2024-07-12 02:29:48 | Re: Should consider materializing the cheapest inner path in consider_parallel_nestloop() |
Previous Message | Tom Lane | 2024-07-12 02:26:47 | Re: Clang function pointer type warnings in v14, v15 |