Melkij

Если материализованное view - то refresh materialized view
Если не материализованное - то закешировано быть не могло. Смотрите определение view и исследуйте, откуда строка в резуультате этого запроса получается.

Ну я бы тоже удивился если бы меня попросили что-то сделать в 6:320. Каким стандартом этот формат времени описывается?

Можем ли мы быть уверены, что в следующей конструкции обновление обязательно произойдет (считаем что SELECT вернул какие-то данные)?

Нет, не можем.
Два конкурентных запроса могут увидеть одни и те же версии строк в cte (не пересекутся на читающих блокировках даже с конкурентными писателями т.к. mvcc) и затем пойдут обновлять одни и те же строки. На блокировках обновления строк их транзакции и сериализуются. Кстати, можно и deadlock словить если строк к обновлению будет несколько и они вернутся из запроса в разном порядке.

приостановить запрос и посмотреть что будет, если произойдет X?

gdb может приостановить всё что угодно. Правда далее уже интересный момент что надо найти куда именно break point ставить.

Посмотрите в vgdisplay есть ли Free PE. Если 0 - расширять просто нечем.

Если free есть - то lvresize или lvextend. Затем расширить файловую систему (resize2fs для ext2/3/4 который у вас вероятно и есть)
Если free нет - то необходимо добавлять новый диск или уменьшать другие разделы. Например, /home . Впрочем, судя по его размеру и 45мб занятых - вы разрезали диск неверно для своей задачи (а зачем вообще резали отдельно /var и /home ?). Может лучше будет вовсе перемонтировать раздел с /home куда-нибудь, скопировать в корневой /home данные и удалить этот том полностью.
Если /home вам нужен отдельный - то опять же resize2fs или какая у вас там файловая система стоит. Сжимаете до какого-то размера (если возможно), проверяете что сжалась, затем уменьшаете логический том (lvresize). Имеет смысл запросить resize2fs меньше размера на который хотите уменьшить раздел. затем после lvresize ещё раз вызвать resize2fs и расширить раздел обратно - чтобы случайно не ошибиться на пару мегабайт и не повредить этим файловую систему.

Мой хрустальный шар совершенно верно показал.
Когда вы делаете add column columnname text - вы получаете NULL во всей этой колонке. Разумеется сразу после этого вы поставить NOT NULL не можете никак. Любая строка нарушает это ограничение и база отказывается ставить NOT NULL.
Когда вы делаете add column columnname text NOT NULL - чтож, это может сработать в одном случае - у вас пустая таблица. Тогда ни одна строка не нарушает NOT NULL ограничение, у вас просто 0 строк. Если хоть одна строка есть - это невозможно. Вы просите default NULL и одновременно NOT NULL - так не бывает. В сообщении об ошибке говорится именно о добавляемой в этот момент колонке, не о какой-то другой существовавшей ранее.

Вы должны указать какой-то не NULL default если хотите поставить NOT NULL на создаваемое поле. Либо очистить таблицу.
Либо создать без NOT NULL, заполнить поле, потом уже делать NOT NULL.

В postgresql действительно колонка не удаляется никогда. Но это деталь реализации и к сути вашего вопроса отношения не имеет.

Не "оператор" потому что а statement - и будет сразу немного понятнее о чём речь.

Первый delete пришёл через extended protocol так же известный как prepared statements. Рядом помимо execute должны быть ещё parse и bind.
Второй - через simple query протокол, то есть просто текст запроса.

Поставить pg_stat_statements, спустя какое-то время посмотреть что тот собрал. Например, нашим отчётом

Слово namespace здесь неверно.
Ищите по schema name и конкретно search_path

Странно что вы не знаете что такое search_path, но он у вас модифицирован. В дефолтную настройку схема public включена и потому оба ваших запроса обычно делают одно и то же.

В доктрине начиная с 2.5 схема указывается так:

/**
 * Clerk
 *
 * @Table(schema="schema")
 */
class Clerk { }

Не уверен что будет работать для public схемы если доктрина предполагает что оно в search_path есть и так.

Чтобы:
- без особой пользы в разы увеличить объём хранимых данных. Тем более если использовать строки.
- постараться запутать планировщик базы
- дополнительно увеличить стоимость записи индексов (значения случайны = значения пишутся в случайные места дерева, вы постоянно "пачкаете" разные страницы)

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