Re: PATCH: Attempt to make dbsize a bit more consistent
От | David Zhang |
---|---|
Тема | Re: PATCH: Attempt to make dbsize a bit more consistent |
Дата | |
Msg-id | 112c2f47-6560-3afb-fc8b-b5cc4040b17d@highgo.ca обсуждение исходный текст |
Ответ на | Re: PATCH: Attempt to make dbsize a bit more consistent (gkokolatos@pm.me) |
Ответы |
Re: PATCH: Attempt to make dbsize a bit more consistent
|
Список | pgsql-hackers |
On 2020-09-09 12:41 a.m., gkokolatos@pm.me wrote: > ‐‐‐‐‐‐‐ 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? I would suggest to keep the original logic unless there is a bug. -- David Software Engineer Highgo Software Inc. (Canada) www.highgo.ca
В списке pgsql-hackers по дате отправления: