0 added
0 removed
Original
2026-01-01
Modified
2026-03-10
1
<p>Теги: postgresql, операции с таблицами</p>
1
<p>Теги: postgresql, операции с таблицами</p>
2
<p>В этой статье рассмотрим такие операции, как создание, удаление и переименование таблицы.</p>
2
<p>В этой статье рассмотрим такие операции, как создание, удаление и переименование таблицы.</p>
3
<h2>Создание таблицы</h2>
3
<h2>Создание таблицы</h2>
4
<p>В общем случае операция добавления таблицы является одной из немногих операций, о которых не стоит особо переживать. Дело в том, что изменяемый нами объект чисто технически не способен в этот самый момент использоваться.</p>
4
<p>В общем случае операция добавления таблицы является одной из немногих операций, о которых не стоит особо переживать. Дело в том, что изменяемый нами объект чисто технически не способен в этот самый момент использоваться.</p>
5
<p>Большая часть параметров по созданию таблицы не влияют на другие объекты вашей БД. А добавление внешнего ключа в случае определения таблицы заставит СУБД получить на упомянутой таблице блокировку уровня<strong>SHARE ROW EXCLUSIVE</strong>. Таким образом будут остановлены DDL-запросы, как и модификации строк. Но несмотря на тот факт, что данная блокировка не должна быть чересчур долгой, то о ней надо помнить, впрочем, как и о любой другой операции, которая вызывает блокировку. Следовательно, хорошей практикой является разделение этих 2-х операций: сначала создайте таблицу и лишь потом добавляйте внешний ключ.</p>
5
<p>Большая часть параметров по созданию таблицы не влияют на другие объекты вашей БД. А добавление внешнего ключа в случае определения таблицы заставит СУБД получить на упомянутой таблице блокировку уровня<strong>SHARE ROW EXCLUSIVE</strong>. Таким образом будут остановлены DDL-запросы, как и модификации строк. Но несмотря на тот факт, что данная блокировка не должна быть чересчур долгой, то о ней надо помнить, впрочем, как и о любой другой операции, которая вызывает блокировку. Следовательно, хорошей практикой является разделение этих 2-х операций: сначала создайте таблицу и лишь потом добавляйте внешний ключ.</p>
6
<h2>Удаление таблицы</h2>
6
<h2>Удаление таблицы</h2>
7
<p>Эта операция, как известно, требует блокировки уровня<strong>ACCESS EXCLUSIVE</strong>. Конечно, если таблица не используется, удалить ее можно вполне спокойно. Однако до того, как вы выполните команду<strong>DROP TABLE...</strong>, проверьте код и документацию, чтобы убедиться, что все упоминания о таблице стерты на самом деле. Для перепроверки запросите у СУБД статистику использования таблицы, применяя представление pg_stat_user_tables2.</p>
7
<p>Эта операция, как известно, требует блокировки уровня<strong>ACCESS EXCLUSIVE</strong>. Конечно, если таблица не используется, удалить ее можно вполне спокойно. Однако до того, как вы выполните команду<strong>DROP TABLE...</strong>, проверьте код и документацию, чтобы убедиться, что все упоминания о таблице стерты на самом деле. Для перепроверки запросите у СУБД статистику использования таблицы, применяя представление pg_stat_user_tables2.</p>
8
<h2>Переименование таблицы</h2>
8
<h2>Переименование таблицы</h2>
9
<p>Переименование таблицы требует уровня<strong>ACCESS EXCLUSIVE</strong>. Вряд ли ваш код сможет безопасно обработать эту операцию непосредственно на лету - все это станет возможным лишь в том случае, если в таблицу никто не пишет, как и не запрашивает из нее каких-либо данных.</p>
9
<p>Переименование таблицы требует уровня<strong>ACCESS EXCLUSIVE</strong>. Вряд ли ваш код сможет безопасно обработать эту операцию непосредственно на лету - все это станет возможным лишь в том случае, если в таблицу никто не пишет, как и не запрашивает из нее каких-либо данных.</p>
10
<p>На практике желательно избегать переименований везде, где возможно. Однако когда переименование таблицы действительно необходимо, то вот советы для обеспечения безопасности:</p>
10
<p>На практике желательно избегать переименований везде, где возможно. Однако когда переименование таблицы действительно необходимо, то вот советы для обеспечения безопасности:</p>
11
<ol><li>Создайте новую таблицу с той же схемой, как и предыдущая.</li>
11
<ol><li>Создайте новую таблицу с той же схемой, как и предыдущая.</li>
12
<li>Скопируйте данные в новую таблицу из старой.</li>
12
<li>Скопируйте данные в новую таблицу из старой.</li>
13
<li>Создайте триггеры к старой таблице на INSERT и UPDATE, чтобы в случае ее применения поддерживалось актуальное состояние новой таблицы.</li>
13
<li>Создайте триггеры к старой таблице на INSERT и UPDATE, чтобы в случае ее применения поддерживалось актуальное состояние новой таблицы.</li>
14
<li>Начните применять новую таблицу.</li>
14
<li>Начните применять новую таблицу.</li>
15
</ol><p>Возможны и другие подходы, которые основаны на использовании представлений (views) либо правил (RULE). Они тоже могут пригодиться -- все будет зависеть от нужной вам производительности.</p>
15
</ol><p>Возможны и другие подходы, которые основаны на использовании представлений (views) либо правил (RULE). Они тоже могут пригодиться -- все будет зависеть от нужной вам производительности.</p>
16
<p><em>По материалам статьи "<a>PostgreSQL at Scale: Database Schema Changes Without Downtime</a>".</em></p>
16
<p><em>По материалам статьи "<a>PostgreSQL at Scale: Database Schema Changes Without Downtime</a>".</em></p>
17
17