ну и функция то в итоге появилась )) в 12 версии

меня не это удивляет
ну вот пример, я не будучи суперпользователем вижу ведь все tablespace'ы и сколько они занимают места
док говорит, что для временных файлов можно определить temp_tablespaces, но, опять же, в моем сетапе это не сделано и спейса два: pg_global, pg_default, и судя по pg_tablespace_size() временные файлы ни в одном из них не учтены

либо диск сожрало что-то другое, либо я не понимаю как это работает :)

А я Вас так и не понял. ;)
Каким образом это должно работать — ведь по самому запросу (или значениям параметров в условиях в нём) должно быть понятно, к какой таблице нужно обратиться, так?

все обсуждение не читал
возможно вам помогут функции
pg_ls_dir и pg_stat_file

Нет, не надо различать таблицы в том и суть, что данные должны сливаться и быть неразличны для запроса через этот мифический индекс или сущность

суперпользователя нет, есть только владелец БД и интерфейс sql

без прав сомнительно, что вы сможете получить информацию

вот это и печалит

Который работает с помощью магии, не иначе.
Как Вы себе представляете что-то, решающее, из какого источника нужно выбрать данные для данного запроса, при этом заведомо не имея информации для такого выбора (это про вариант "несколько таблиц")?!

А по поводу "слияния" — можно написать кучу триггеров, которые будут сбрасывать все данные из этих таблиц в какую-то одну, и индексировать уже её, и к ней выполнять запросы.
Но обычно это совершенно не нужно. Мне кажется, что Вы что-то не то / не так решаете.

а мониторинг
temp_files и temp_bytes из pg_stat_database - это не поможет вам?

temp_bytes показывает сейчас значение 228Тб, при диске в 1.3Тб это не то

нет, там дельту нужно смотреть

нужно тогда думать можно ли (и когда) сбрасывать эту статистику

посмотрите pg_stat_reset()

вы же какой-то DBaaS пользуетесь? там разве нет встроенного мониторинга?

зачем ее сбрасывать? вам нужны только дельты

на будущее можно, конечно, подумать об этом
но хотелось бы в моменте понимать весь расклад по месту в базе

думаю, что это не проблема

в целом ситуация выглядит так
несколько запросов погибло по "could not write to hash-join temporary file: No space left on device"
мониторинг вендора сказал, что 500Гб оказалось в моменте занято некими "system resources"
захотелось понять - эти "system resources" - это действительно временные файлы, потому что случился какой-то скачок нагрузки и в базу пришло слишком много запросов, или произошло что-то еще