А вот такой вопрос насчёт PREPARE и EXECUTE.

В рамках текущего соединения сделал тот самый PREPARE.

Далее дёргаю EXECUTE каждый раз с новыми данными, и он отрабатывает очень медленно (5 сек). Вот выхлоп EXPLAIN:

QUERY PLAN                                                      
----------------------------------------------------------------------------------------------------------------------
Insert on tablename  (cost=0.00..10.00 rows=500 width=1350) (actual time=5033.969..5033.970 rows=0 loops=1)
  ->  Values Scan on "*VALUES*"  (cost=0.00..10.00 rows=500 width=1350) (actual time=0.033..11.220 rows=500 loops=1)
Planning Time: 11.610 ms
Execution Time: 5034.032 ms
(4 rows)

Почему так? С PREPARE же, вроде, быстрее должно быть.

а медленно относительно чего ?
тут вроде вносится 500 строк ?
аналогичный запрос , но без PREPARE как выполняется ?

почему это
to_date(‘27.03.2021’, ‘DD.MM.YYYY’)
выдает ошибку
ERROR: syntax error at or near ".03"

ковычки не правильные

обратные ковычки указывают на название сущности, а сущности не могут быть через точку
нужны одинарные обычные кавычки

Так он и быстрее... просто это несущественно по сравнению с общим временем выполнения, скорее всего (кстати, этой разницы в explain большей частью не видно, потому что это время parsing и planning, а последнее (план) кешируется только после нескольких повторов).

Ребят, как посмотреть список таблиц в определенном TABLESPACE ?

Например TABLESPACE “fias”

тут ещё одна “прелесть” у wal-e обнаружилась: они не стесняются лезть во внутреннее состояние базы и менять статусы архивации WAL-сегментов, если включена параллельность для wal-push (а она по умолчанию включена): https://github.com/wal-e/wal-e/blob/master/wal_e/worker/pg/wal_transfer.py#L30
в результате, для некоторых сегментов archive_command не вызывается, совсем.

я это заметил во время миграции на pgbackrest по дыркам в последовательности WAL и долго не понимал что вообще происходит.

я бы добавил предупреждение на эту тему.
как и рекомендацию не использовать wal-e для новых проектов как минимум.

Есть варианты ?

\dt+ fias.*

это схема таки

Уже вижу.

select oid::regclass from pg_class where relkind='r' and reltablespace=(SELECT oid FROM pg_tablespace WHERE spcname='ebs');

ebs - название TABLESPACE?

А это приведение к regclass чё сделает? Сколько пользовался - ни разу не посмотрел глазами. Всегда параметр передавал.

Однако, спасибо большое! Обновил.

да

конвертирует OID в соответствующий тип, можно посмотреть все подобные типы в базе \dTS reg*

в случае с таблицами, учитывается search_path и, при необходимости, префикс схемы добавляется