Melkij

мне сно , при апдейте кортежа в varchar запись удаляется с диска и вписывается на новое место в памяти

Ммм. Сомневаюсь что действительно что-то ясно.

Для начала:
на диске данные существуют ровно в том же виде, что и затем обрабатываются в памяти. Как побочного следствие именно этого, кстати, базы postgresql физически не переносимы на другие процессорные архитектуры, только dump/restore или ещё какую логическую репликацию. А ещё есть забавный фокус выравнивания структур данных в памяти. Из-за чего при разном порядке столбцов в таблице идентичный объём записанных данных может различаться по требуемому месту на дисках.

postgresql - mvcc база. При удалении строки запись не удаляется. Вообще. Только проставляется xmax и страничка отмечается грязной. Операции обновления строки не существует вовсе. Update - это всегда delete + insert. Обновлённая запись при этом попадает в отличающееся место таблицы, так, что в таблице одновременно существую и старая и новая версии строки. И их может быть много.
(enterprisedb грозятся доделать zheap в pg13, так что может будет веселее, но в версиях до 11 гарантированно как я описал, в 12 - только если вы смелый человек и будете собирать экспериментальные расширения)
Итак, далее приходит autovacuum или vacuum, строки которые уже никому не могут быть видны вычищаются и считаются пустым пространством, в том числе по free space map.

Пишущие операции пытаются найти место под запись:
- в той же самой странице данных
- в какой-то странице начиная от начала таблицы
- в худшем случае создают новую страницу

Да, может быть что остались области в датафайлах, в которых ничего нет и даже ничего полезного туда и не поместится.

занимаемой процессом памяти на жестком диске

Что это такое?
Если интересен формат датафайлов - то вам дорога в исходники базы. Для ОС выделяются блоки на диске по 8кб и в них хранится какая-то бинарная штука.

Касательно private памяти backend'а - в postgresql есть менеджер памяти, называемый memory context. backend память запрашивает у ОС блоками, что-то делает что ему надо используя эту память под всякую мелочь или не очень мелочь, затем memory context обнуляется или удаляется и память возвращается ОС. Большинство контекстов существуют не долго, на транзакцию или на запрос, например.
Отладчик широко распространён - gdb. Без dbg сборки, впрочем, там явно будет ничего не понятно.

Смотрите в код и думайте, что ваш код выполняет на самом деле. Смотрите отладчиком содержимое переменных либо банально распечатайте их.

1) Вы сначала делаете match (не знаю зачем, ну да ладно, не о том вопрос).
2) Затем обходите результаты.
3) Затем игнорируете то что вы нашли и по всё той же регулярке что в пункте 1 заменяете всё в строке на певрое совпадение.

Результат совершенно логичен. Исправьте логику, чтобы заменять в теле цикла только одно соответствующее совпадение.

Через preg_replace это делать банально проще и удобнее, чем match + цикл по нему. А есть ещё preg_replace_callback если просто replace не хватает.

Пароли скорей всего сохранены как md5. Метод scram-sha-256 появился только в 10 и включая 12 релиз ещё не используется по-умолчанию (проблем с базой нет, сообщество даёт время на реализацию этого протокола в клиентских библиотеках, чтобы не как с mysql 8.0 получилось).

Хэши паролей md5 можно найти в pg_authid таблице системного каталога, считаются как

select rolpassword = ('md5' || md5('some password' || rolname)) from pg_authid where rolname = 'username';

То есть восстановить исходный пароль невозможно. Можно попробовать подобрать коллизию для хэша.

Никак.
view не хранит никаких данных, а раз нет данных - то не по чему строить индекс.
Пример принципиальной проблемы индекса на view: если сделать view вида select foo, avg(bar) from tablename group by foo; - как пересчитывать данные при изменении строк в tablename?

Индекс может быть создан на материализованном представлении (materialized view) - потому что такое представление данные хранит непосредственно. Но обновлять эти данные требуется вручную запросом REFRESH MATERIALIZED VIEW, который выполнит запрос, запишет его результат в новый heap, затем заменит старый heap новым (если не указан concurrently) либо обновит несовпадающие строки (для concurrently)

Мне это в последующем надо применить в условии
if ($interval > 7){...

$datetime1 = date_create('2019-05-16');
if ($datetime1 < new datetime('-7 day'))

?
Для datetime сделаны операторы сравнения родные.

Ищите где выставлен statement_timeout. Такая ошибка именно по срабатывании этой настройки. И включать её надо намеренно. Так что ищите где ставится, от конфига СУБД, настроек базы и пользователя до руками сделанного set в приложении.

Вот честно могу ответить - ни малейших представлений как можно абстрактно сказать, сколько памяти займёт client backend процесс базы.
Это будет меняться от:
- очевидно версии базы, плюс от компилятора и настроек сборки
- session_preload_libraries, work_mem (к слову о work_mem - вы знаете, что один запрос может использовать несколько work_mem?), temp_buffers. Да ещё maintenance_work_mem для некоторых операций
- величины системного каталога - как pinned таблиц, так и затем кэшированных при обращениях
- выполняемых ранее запросов. Тот же кэш хранимых процедур у каждого backend свой

Один backend вполне и десятки гб памяти может использовать и такие настройки может иметь смысл делать для, например, построения индекса.

Помимо собственной private памяти на каждое активное соединение всё множество max_connections резервирует себе некоторое место в сегменте разделяемой памяти, независимо от того, сколько соединений вы затем используете.

Чтобы админить калькуляторы и чайники обычно DBA не нанимают. Тем более если на том же самом калькуляторе помимо базы ещё и приложение отъедает непредсказуемо сколько памяти. Чего там от этого 1гб останется? Видимо даже shared_buffers с 128мб поднимать некуда, а то может и уменьшать придётся. Так что по опыту сложно что-то сказать о такой конфигурации.

Скорей всего не трогайте max_connections. Оставьте дефолтные 100.

Правильно ли я понимаю, что пул соединений не помогает в плане экономии оперативной памяти

Смотря какой пул и как работает приложение.
pgbouncer в pool_mode = transaction вполне может свести пару сотен подключений к баунсеру на десяток коннектов в базе. Ну а 10 процессов базы будут использовать наверняка поменьше памяти чем 200.
Для pool_mode = session - да, только сгладить стоимость fork годится.

select day /*, ... */ 
from tablename 
join lateral generate_series(start_date, end_date, interval '1day') as day on true 
where to_char(day, 'Day') = week_day

если в лоб и у вашего week_day (который с весьма не ясной причиной хранится в varchar) написание совпадает с to_char.

Это странный способ написать:

$b = 'dd';
$obj->dd;

физически бэкапить определённые базы

Не сможете.
Ну в смысле скопировать отдельные файлы можете. А вот восстановить потом - нет. Никогда.
Бекапить можно только целиком весь datadir, со всеми симлинками. Правильно объяснив базе что вы её бекапите и соблюдая ожидания базы по методу её бекапа чтобы из этого потом можно было восстановиться.

А директории баз называются идентично полю oid в pg_database

index (func1, func2) - это в корне не то же самое что func1 || func2
Выражения для оператора разные, поэтому индекс отбрасывается как неподходящий.

В общем случае фильтр по выражению может работать по индексу только построенному в точности по такому же выражению.

А вы про какую версию спрашиваете? Синтаксис var_dump для объекта выглядит как: https://github.com/php/php-src/blob/PHP-7.2/ext/st...

%sobject(%s)#%d (%d) {

В самом начале возможен символ & - если это ссылка.
Второй %s - имя класса.
следующий %d - идентификатор объекта
последний %d - число свойств объекта

Что немного не похоже на object(PDO)[1]. Да и не менялся формат уже давно.

-depth Process each directory's contents before the directory itself.
The -delete action also implies -depth.

Это просто не тот параметр, который вы искали. Уровни вложенности это -maxdepth и -mindepth. То есть

find -maxdepth 1 -type f

basebackup - это буквально копирование почти всего из PGDATA тупо на уровне файликов.
Строго в один поток. (ну, на самом деле в отдельном потоке walreceiver ещё если wal method выставлен stream)

Смотрите внимательнее куда упираетесь. Диск на чтение откуда снимаете? Диск куда пишете? Сеть? Одно ядро CPU на базе с которой снимаете? На которую пишете?
Несколько гигабит занять в общем-то не проблема.

СУБД однозначно отвечает, что не согласна с синтаксисом.

Если не читать списки зарезервированных слов - то да, может быть не совсем очевидно почему этот запрос синтаксически неверен. Но тем не менее слово user всё равно зарезервировано и стандартами SQL и конкретной реализацией в postgresql. А потому не может использоваться в качестве unquoted идентификатора.