Re: PATCH: Add hooks for pg_total_relation_size and pg_indexes_size - Mailing list pgsql-hackers

From Abdoulaye Ba
Subject Re: PATCH: Add hooks for pg_total_relation_size and pg_indexes_size
Date
Msg-id CA+-ifObTf=5p8bAgVZYXOrOpPi3J=6nn7KBXtBJJqCm=qMn3VA@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: Add hooks for pg_total_relation_size and pg_indexes_size  (Andreas Karlsson <andreas@proxel.se>)
Responses Re: PATCH: Add hooks for pg_total_relation_size and pg_indexes_size
List pgsql-hackers


On Fri, 9 Aug 2024 at 18:10, Andreas Karlsson <andreas@proxel.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.

pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Restart pg_usleep when interrupted
Next
From: Tom Lane
Date:
Subject: Re: is_superuser versus set_config_option's parallelism check