powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Мешают ли колонки полям ти text или varchar?
10 сообщений из 10, страница 1 из 1
Мешают ли колонки полям ти text или varchar?
    #39262289
azsx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня таблицы на миллионы записей (от 2 млн до 30 млн, по несколько гб). Данные в таблицах достаточно уникальны, использую отношения только при явной необходимости. С данными проводится много внешних обработок, при чем если запись 1 раз обработана, то ее либо больше не надо обрабатывать совсем, либо обрабатывать через время (например, через месяц). Обработка может на выходе давать текстовой результат. Обработки иногда добавляются новые.
Что я делаю сейчас.
Есть таблица, типа
Код: plsql
1.
CREATE TABLE test_table (id_pole1 bigserial, name_pole2 varchar(255) not null UNIQUE, pole3 boolean, pole4 boolean, pole5 boolean, pole6 boolean, sss_pole7 text, fff_pole8 text);


При этом если мне надо добавить или удалить поле в таблицу, я это спокойно делаю. Особенно часто добавляю boolean поля, бывает и другие типы. Например, сейчас мне логично добавить 3 поля байт, а text убрать.
Вопрос?
А правильно ли я понимаю, что для системы postgresql не имеет значения как я балуюсь полями, если я настроил автоочистку на 200 тысяч записей, то вполне допустимо хранить поле text и другие поля в одной таблице? Или поле text должно быть вынесено в отдельную таблицу и использоваться как key - value, а все остальные поля только в отдельной таблице?
Производительность меня пока устраивает, просто хочу понять как правильно делать.
...
Рейтинг: 0 / 0
Мешают ли колонки полям ти text или varchar?
    #39262354
Локшин Марк
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
azsx,

TOAST
...
Рейтинг: 0 / 0
Мешают ли колонки полям ти text или varchar?
    #39262415
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
azsxПри этом если мне надо добавить или удалить поле в таблицу, я это спокойно делаю. Особенно часто добавляю boolean поля, бывает и другие типы. Например, сейчас мне логично добавить 3 поля байт, а text убрать.
Вопрос?
А правильно ли я понимаю, что для системы postgresql не имеет значения как я балуюсь полями,

неправильно.

посмотрите pg_attribute[s] -- все ваши дропнутые поля остаются в таблице. более того -- остаются с данными (до вакуум фулла). можете написать тестовый скриптик на добавление и удаление полей -- рано или поздно вы вылезете за предел спеки.

логично на этапе макетирования не обращать на это внимания. но для работы -- надо много думать, прежде чем дропнуть поле в большой табличке. иногда лучше его перестать пользовать и заполнять. а по надобности -- опять заюзать.
...
Рейтинг: 0 / 0
Мешают ли колонки полям ти text или varchar?
    #39262449
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
azsx,

Нужно помнить о том, что:
ПЖ имеет 2 типа значений — фиксированной и переменной длины

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

для ускорения доступа все фиксированные значения выравниваются по границе размерности архитектуры

существует MVCC, который при изменении записей "раздувает" таблицы

Сделайте 2 таблички и сравните их размеры:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
CREATE TABLE a(
  f1 int2,
  f2 int8,
  f3 int2,
  f4 int8,
  f5 int2,
  f6 int8,
  f7 int2,
  f8 int8 );

CREATE TABLE b(
  f1 int2,
  f3 int2,
  f5 int2,
  f7 int2,
  f2 int8,
  f4 int8,
  f6 int8,
  f8 int8 );

INSERT INTO a SELECT 1,2,3,4,5,6,7,8 FROM generate_series(1,1000000);
INSERT INTO b SELECT 1,2,3,4,5,6,7,8 FROM generate_series(1,1000000);

SELECT relname,pg_total_relation_size(oid) FROM pg_class WHERE relname IN ('a','b');


А теперь создайте новые колонки и опять — размер:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
ALTER TABLE a ADD f9 int2;
SELECT relname,pg_total_relation_size(oid) FROM pg_class WHERE relname IN ('a');

ALTER TABLE a ADD f10 int2 NOT NULL DEFAULT 0;
SELECT relname,pg_total_relation_size(oid) FROM pg_class WHERE relname IN ('a');

ALTER TABLE a DROP f10;
SELECT relname,pg_total_relation_size(oid) FROM pg_class WHERE relname IN ('a');



Также можно сравнить размеры таблиц, в которых:

одно текстовое поле фиксированной длины, скажем `varchar(10)`

одно поле `text` c "простыми" данными длиной более 4000, скажем `repeat('a', 4000)`

одно поле `text` со "сложными" данными (уж сгенерируйте как-то)

Мое мнение — необходимость частых изменений в структуре таблиц говорит о плохой модели данных и приводит к ненужному геморою у админов.
...
Рейтинг: 0 / 0
Мешают ли колонки полям ти text или varchar?
    #39262463
azsx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Всем спасибо за ответы.
Таким образом, получается:
1. Таблица чиститься более менее только при vacuum full, который блокирует таблицу. При этом на тестовой таблице чистка воспроизвелась не полностью, но атоочистка на тесте не очистила совсем ничего.
2. Немного помогает сжать таблицу постоянные update. Зато благодаря им же возможны пропуски внутри таблицы на десятки байт на каждой странице, которые уже не заполняться ничем и никогда.
3. Радикальным решением (как и с индексом) будет создание копии таблицы, удаление старой, переименование новой.
Я всё правильно понял?
---
Таким образом в моей ситуации надо:
1. не удалять поле фиксированной длины в большой таблице, а переименовать его в поле "clear_1", а затем когда понадобиться поле такой же размерности снова его использовать. Это для экономии места. Верно?
2. Зато непонятно, что делать с полем переменной длины и тем более полем text больше 2 кбайт. Его таки лучше удалять и пусть pg сам чистит базу как хочет автоочисткой? Или использовать потом снова, не смотря на то, что данные будут однозначно другими и другой размерностью? Или что то еще?
3. Радикальным решением судя по всему является вынесение всех служебных полей, особенно тех, которые возможно придется удалять, в другие таблицы. То есть если поле переменной длины, записи часто удаляют - то лучше для места на диске под такое поле делать отдельную таблицу. Верно?
...
Рейтинг: 0 / 0
Мешают ли колонки полям ти text или varchar?
    #39262464
azsx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
любопытно, а есть БД где полная очистка таблиц от старых записей проходит без общей блокировки всей таблицы?
...
Рейтинг: 0 / 0
Мешают ли колонки полям ти text или varchar?
    #39262482
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
azsx,

ORACLE, там механизм версионности другой.
Соответственно, что-то лучше (в таблицах и индекс всегда только актуальные данные), а что-то — совсем нет (время ROLLBACK, snapshot too old).
...
Рейтинг: 0 / 0
Мешают ли колонки полям ти text или varchar?
    #39262509
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vyegorovORACLE, там механизм версионности другой.
Ну... да... это не отменяет блокировок при DDL-ах...
...
Рейтинг: 0 / 0
Мешают ли колонки полям ти text или varchar?
    #39262525
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
azsx2. Немного помогает сжать таблицу постоянные update. Зато благодаря им же возможны пропуски внутри таблицы на десятки байт на каждой странице, которые уже не заполняться ничем и никогда.вы можете перед дропом / вместо дропа сказать апдейт сет НУЛЛ в "дропаемое" -- а потом пустить простой вакуум. этот апдейт можно отдать джобу, и резать хвост по частям. всяко можноazsx3. Радикальным решением (как и с индексом) будет создание копии таблицы, удаление старой, переименование новой.
Я всё правильно понял?а это и есть вакуме фуул. только рукаме. хотя нет , ваккуум--фулл не удаляет дропнутых столбцов, но обнуляет. а пересоздание -- удаляет

но при наличии конкурентов это невозможно. (надо где--то в середине подсунуть конкурентам витрину вмест старого/нового, понапихать инстеад--оффов, запустить джобы на перекачку, т.е. масса хенджоба. и то -- если фкеев нет)
azsx3. Радикальным решением судя по всему является вынесение всех служебных полей, особенно тех, которые возможно придется удалять, в другие таблицы. То есть если поле переменной длины, записи часто удаляют - то лучше для места на диске под такое поле делать отдельную таблицу. Верно? сначала подумайте об индексах. а так -- соображение верное -- хранить большие не меяющиеся куски отдельно от часто меняющихся записей, до тех пор, пока сквозные индексы не потребуются. радикальным было бы решение с мультитабличными индексами, или вообще с индексами "без овнеров" (с мультиовнером) -- которые вы могли бы поддерживать триггерами, но это -- очень большой логический скачок -- как его втемяшить оптимайзеру -- тут какой--то простой арифметики не получается. и придется прямо обращаться руками к индексам -- что--то типа М--систем, наверное вылезет.
...
Рейтинг: 0 / 0
Мешают ли колонки полям ти text или varchar?
    #39262714
Jonhson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vyegorovvyegorovORACLE, там механизм версионности другой.
Ну... да... это не отменяет блокировок при DDL-ах...

вообще-то есть online, так что ваша информация несколько устарела
...
Рейтинг: 0 / 0
10 сообщений из 10, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Мешают ли колонки полям ти text или varchar?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]