Re: PATCH: Attempt to make dbsize a bit more consistent

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: gkokolatos(at)pm(dot)me
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Soumyadeep Chakraborty <soumyadeep2007(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, David Zhang <david(dot)zhang(at)highgo(dot)ca>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: PATCH: Attempt to make dbsize a bit more consistent
Date: 2021-04-08 08:04:35
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, Mar 17, 2021 at 02:35:28PM +0900, Michael Paquier wrote:
> So we would likely want a separate function. Another possibility,
> which I find tempting, would be to push down the calculation logic
> relying on physical files down to the table AM themselves with a new
> dedicated callback (relation_size_physical?), as it seems to me that
> the most important thing users want to know with this set of functions
> is how much physical space is being consumed at one given point in
> time. Attached is a small prototype I was just playing with.

Thinking more about that, I'd be rather in favor of having a new table
AM callback to let the AM measure the size of physical files, and make
the business of dbsize.c fall under that. It is clear that this needs
more work, so I have marked it as returned with feedback.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-04-08 08:10:43 Re: Support for NSS as a libpq TLS backend
Previous Message Bharath Rupireddy 2021-04-08 08:00:58 Re: Can we remove extra memset in BloomInitPage, GinInitPage and SpGistInitPage when we have it in PageInit?