From: | Abdoulaye Ba <abdoulayeba29(at)gmail(dot)com> |
---|---|
To: | Andreas Karlsson <andreas(at)proxel(dot)se> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: PATCH: Add hooks for pg_total_relation_size and pg_indexes_size |
Date: | 2024-08-09 16:59:37 |
Message-ID: | CA+-ifObTf=5p8bAgVZYXOrOpPi3J=6nn7KBXtBJJqCm=qMn3VA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 9 Aug 2024 at 18:10, Andreas Karlsson <andreas(at)proxel(dot)se> wrote:
> On 8/8/24 2:18 PM, Abdoulaye Ba wrote:
> > I am submitting a patch to add hooks for the functions
> > pg_total_relation_size and pg_indexes_size. These hooks allow for custom
> > behaviour to be injected into these functions, which can be useful for
> > extensions and other custom PostgreSQL modifications.
>
> What kind of extensions do you imagine would use this hook? If it is for
> custom index AMs I think adding this to the index AM interface would
> make more sense than just adding a generic callback hook.
>
> Andreas
>
> The primary use case for this hook is to allow extensions to account for
> additional storage mechanisms that are not covered by the default
> PostgreSQL relation size calculations. For instance, in our project, we are
> working with an external indexing system (Tantivy) that maintains
> additional data structures outside the standard PostgreSQL storage. This
> hook allows us to include the size of these additional structures in the
> total relation size calculations.
>
> While I understand your suggestion about custom index AMs, the intent
> behind this hook is broader. It is not limited to custom index types but
> can also be used for other forms of external storage that need to be
> accounted for in relation size calculations. This is why a generic callback
> hook was chosen over extending the index AM interface.
>
> However, if there is a consensus that such a hook would be better suited
> within the index AM interface for cases involving custom index storage, I'm
> open to discussing this further and exploring how it could be integrated
> more tightly with the existing PostgreSQL AM framework.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2024-08-09 17:03:02 | Re: Add LSN <-> time conversion functionality |
Previous Message | Tristan Partin | 2024-08-09 16:49:08 | Re: Building with meson on NixOS/nixpkgs |