Re: PATCH: Attempt to make dbsize a bit more consistent
| От | gkokolatos@pm.me |
|---|---|
| Тема | Re: PATCH: Attempt to make dbsize a bit more consistent |
| Дата | |
| Msg-id | 9dlpLBlL7RCWWMDOy0RwMK0Sz_hKNd6GVscSiP8y1RUe1xpn-EHLsnMu_mFixMZ-rz1l_KYEXKyPxU1qLF0KWhH_Qe8kOjmlgz0uIxJnGXU=@pm.me обсуждение исходный текст |
| Ответ на | Re: PATCH: Attempt to make dbsize a bit more consistent (David Zhang <david.zhang@highgo.ca>) |
| Ответы |
Re: PATCH: Attempt to make dbsize a bit more consistent
|
| Список | pgsql-hackers |
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, 8 September 2020 22:26, David Zhang <david.zhang@highgo.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?
В списке pgsql-hackers по дате отправления: