Thread: Create syscaches for pg_extension
Shared libraries of extensions might want to invalidate or update their own caches whenever a CREATE/ALTER/DROP EXTENSION command is run for their extension (in any backend). Right now this is non-trivial to do correctly and efficiently. But if the extension catalog was part of a syscache this could simply be done by registering an callback using CacheRegisterSyscacheCallback for the relevant syscache. This change is only made to make the lives of extension authors easier. The performance impact of this change should be negligible, since updates to pg_extension are very rare.
Attachment
út 13. 8. 2024 v 16:13 odesílatel Jelte Fennema-Nio <postgres@jeltef.nl> napsal:
Shared libraries of extensions might want to invalidate or update their
own caches whenever a CREATE/ALTER/DROP EXTENSION command is run for
their extension (in any backend). Right now this is non-trivial to do
correctly and efficiently. But if the extension catalog was part of a
syscache this could simply be done by registering an callback using
CacheRegisterSyscacheCallback for the relevant syscache.
This change is only made to make the lives of extension authors easier.
The performance impact of this change should be negligible, since
updates to pg_extension are very rare.
+1
Pavel
On Tue, Aug 13, 2024 at 5:23 PM Pavel Stehule <pavel.stehule@gmail.com> wrote: > út 13. 8. 2024 v 16:13 odesílatel Jelte Fennema-Nio <postgres@jeltef.nl> napsal: >> >> Shared libraries of extensions might want to invalidate or update their >> own caches whenever a CREATE/ALTER/DROP EXTENSION command is run for >> their extension (in any backend). Right now this is non-trivial to do >> correctly and efficiently. But if the extension catalog was part of a >> syscache this could simply be done by registering an callback using >> CacheRegisterSyscacheCallback for the relevant syscache. >> >> This change is only made to make the lives of extension authors easier. >> The performance impact of this change should be negligible, since >> updates to pg_extension are very rare. > > > +1 +1 from me too ------ Regards, Alexander Korotkov Supabase
čt 5. 9. 2024 v 15:41 odesílatel Andrei Lepikhov <lepihov@gmail.com> napsal:
On 22/8/2024 03:49, Michael Paquier wrote:
> On Mon, Aug 19, 2024 at 03:21:30PM +0900, Michael Paquier wrote:
>> I won't hide that I've wanted that in the past..
>
> And I have bumped into a case where this has been helpful today, so
> applied. Thanks!
It had been my dream, too, for years. But the reason was the too-costly
call of the get_extension_oid routine (no less than pgbench 2-3% of
overhead when checked it in the planner hook).
It seems that the get_extension_oid routine was not modified when the
sys cache was introduced. What is the reason? It may be that this
routine is redundant now, but if not, and we want to hold the API that
extensions use, maybe we should rewrite it, too.
See the attachment proposing changes.
+1
Pavel
--
regards, Andrei Lepikhov
On Thu, 5 Sept 2024 at 15:41, Andrei Lepikhov <lepihov@gmail.com> wrote: > It seems that the get_extension_oid routine was not modified when the > sys cache was introduced. What is the reason? It may be that this > routine is redundant now, but if not, and we want to hold the API that > extensions use, maybe we should rewrite it, too. > See the attachment proposing changes. It seems reasonable to make this function use the new syscache. I didn't change any existing code in my original patch, because I wanted to use the syscache APIs directly anyway and I didn't want to make the patch bigger than strictly necessary. But I totally understand that for many usages it's probably enough if the existing APIs are simply faster (on repeated calls). The patch looks fine. But I think get_extension_name and get_extension_schema should also be updated.
On Thu, 5 Sept 2024 at 22:03, Andrei Lepikhov <lepihov@gmail.com> wrote: > Thanks, see new patch in attachment. LGTM now. Added it to the commitfest here: https://commitfest.postgresql.org/50/5241/