Why is it OK for dbsize.c to look at relation files directly?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Why is it OK for dbsize.c to look at relation files directly?
Дата
Msg-id 20190424230956.bg7szlergyywal6c@alap3.anarazel.de
обсуждение исходный текст
Ответы Re: Why is it OK for dbsize.c to look at relation files directly?  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Hi,

To me it seems like a noticable layering violation for dbsize.c to
directly stat() files in the filesystem, without going through
smgr.c. And now tableam.

This means there's code knowing about file segments outside of md.c -
which imo shouldn't be the case.  We also stat a lot more than
necessary, if the relation is already open - when going through smgr.c
we'd only need to stat the last segment, rather than all previous
segments.

Always going through smgr would have the disadvantage that we'd probably
need a small bit of logic to close the relation's smgr references if it
previously wasn't open, to avoid increasing memory usage unnecessarily.


dbsize.c directly stat()ing files, also means that if somebody were to
write a tableam that doesn't store data in postgres compatible segmented
files, the size can't be displayed.


I think we should change dbsize.c to call
RelationGetNumberOfBlocksInFork() for relkinds != TABLE/TOAST/MATVIEW,
and a new AM callback for those. Probably with the aforementioned
additional logic of closing smgr references if they weren't open before
the size computation.

Imo this pretty clearly is v13 work.

I'd assume that pg_database_size*() would continue the same way it does
right now.

Greetings,

Andres Freund



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: TRACE_SORT defined by default
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Why is it OK for dbsize.c to look at relation files directly?