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 по дате отправления: