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

From: gkokolatos(at)pm(dot)me
To: David Zhang <david(dot)zhang(at)highgo(dot)ca>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: PATCH: Attempt to make dbsize a bit more consistent
Date: 2020-09-09 07:41:17
Message-ID: 9dlpLBlL7RCWWMDOy0RwMK0Sz_hKNd6GVscSiP8y1RUe1xpn-EHLsnMu_mFixMZ-rz1l_KYEXKyPxU1qLF0KWhH_Qe8kOjmlgz0uIxJnGXU=@pm.me
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, 8 September 2020 22:26, David Zhang <david(dot)zhang(at)highgo(dot)ca> wrote:

>
>
> I found the function "table_relation_size" is only used by buffer
> manager for "RELKIND_RELATION", "RELKIND_TOASTVALUE" and
> "RELKIND_MATVIEW", i.e.
>
>         case RELKIND_RELATION:
>         case RELKIND_TOASTVALUE:
>         case RELKIND_MATVIEW:
>             {
>                 /*
>                  * Not every table AM uses BLCKSZ wide fixed size blocks.
>                  * Therefore tableam returns the size in bytes - but
> for the
>                  * purpose of this routine, we want the number of blocks.
>                  * Therefore divide, rounding up.
>                  */
>                 uint64        szbytes;
>
>                 szbytes = table_relation_size(relation, forkNum);
>
>                 return (szbytes + (BLCKSZ - 1)) / BLCKSZ;
>             }
>
> So using "calculate_relation_size" and "calculate_toast_table_size" in
> "calculate_table_size" is easy to understand and the original logic is
> simple.
>

You are correct. This is the logic that is attempted to be applied
in dbsize.c in this patch.

So what do you think of the patch?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-09-09 08:01:09 Re: shared-memory based stats collector
Previous Message gkokolatos 2020-09-09 07:36:21 Re: PATCH: Attempt to make dbsize a bit more consistent