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.
Attachments:
v1-0001-Create-syscaches-for-pg_extension.patchtext/x-patch; charset=US-ASCII; name=v1-0001-Create-syscaches-for-pg_extension.patchDownload+3-1
ú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
On Tue, Aug 13, 2024 at 05:38:55PM +0300, Alexander Korotkov wrote:
+1 from me too
I won't hide that I've wanted that in the past..
--
Michael
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!
--
Michael
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.
--
regards, Andrei Lepikhov
Attachments:
0001-Use-EXTENSIONNAME-syscache-to-find-extension-oid.patchtext/plain; charset=UTF-8; name=0001-Use-EXTENSIONNAME-syscache-to-find-extension-oid.patchDownload+3-26
č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
Show quoted text
--
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 5/9/2024 18:50, Jelte Fennema-Nio wrote:
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.
Thanks, see new patch in attachment.
--
regards, Andrei Lepikhov
Attachments:
0001-Lookup-an-extension-data-in-corresponding-syscache.patchtext/plain; charset=UTF-8; name=0001-Lookup-an-extension-data-in-corresponding-syscache.patchDownload+13-70
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/
On Thu, Sep 05, 2024 at 10:56:34PM +0200, Jelte Fennema-Nio wrote:
LGTM now. Added it to the commitfest here:
https://commitfest.postgresql.org/50/5241/
Looks OK at quick glance. I'll take care of that as I've done the
other one.
--
Michael