| 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: | Whole Thread | Raw Message | 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?
| 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 |