Re: PATCH: Add hooks for pg_total_relation_size and pg_indexes_size

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.
>

In response to

Browse pgsql-hackers by date

  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