PostgreSQL: ОБНОВЛЕНИЕ большой таблицы - PullRequest
Новая
       20

PostgreSQL: ОБНОВЛЕНИЕ большой таблицы

0 голосов
/ 29 марта 2019

У меня есть большая таблица PostgreSQL из 29 миллионов строк. Размер (согласно вкладке статистики в pgAdmin составляет почти 9 ГБ.) Таблица включена после ввода с пустым столбцом геометрии.

Я хочу ОБНОВИТЬ столбец геометрии с помощью ST_GeomFromText, считывая из координатных столбцов X и Y (SRID: 27700), хранящихся в той же таблице. Однако выполнение этого запроса сразу по всей таблице приводит к ошибкам «недостаточно места на диске» и «потеря соединения с сервером» ... последние встречаются реже.

Чтобы преодолеть это, я должен ОБНОВИТЬ 29 миллионов строк партиями / стадиями? Как я могу сделать 1 миллион строк (ПЕРВЫЙ 1 миллион), затем сделать следующие 1 миллион строк, пока я не достигну 29 миллионов?

Или есть другие более эффективные способы обновления больших таблиц, подобные этой?

Я должен добавить, что таблица размещена в AWS.

Мой запрос ОБНОВЛЕНИЯ: 

UPDATE schema.table
SET geom = ST_GeomFromText('POINT(' || eastingcolumn || ' ' || northingcolumn || ')',27700);

Ответы [ 2 ]

1 голос
/ 02 апреля 2019

Исходя из моего первоначального вопроса:

Однако выполнение этого запроса сразу для всей таблицы приводит к ошибкам «недостаточно места на диске» и «соединение с сервером потеряно» ...менее часто.

Оказалось, что нашей базе данных экземпляра Amazon AWS не хватило места, и мой исходный запрос ST_GeomFromText не был выполнен.Освобождение места исправило это.

В важной заметке, предложенной @mlinth, ST_Point выполнял мой запрос намного быстрее, чем ST_GeomFromText (24 минуты против 2 часов).

Мой последний запрос: 

UPDATE schema.tablename
SET geom = ST_SetSRID(ST_Point(eastingcolumn,northingcolumn),27700);
1 голос
/ 29 марта 2019

Вы не указали никаких спецификаций сервера, запись 9 ГБ может быть довольно быстрой на недавнем оборудовании.

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

Распространенная уловка для решения этой проблемы (очень длинная транзакция, блокировка записи в таблицу) - разделить UPDATE на диапазоны, основанные на первичном ключе, выполняемом в отдельных транзакциях. 

/* Use PK or any attribute with a known distribution pattern */
UPDATE schema.table SET ... WHERE id BETWEEN 0 AND 1000000;
UPDATE schema.table SET ... WHERE id BETWEEN 1000001 AND 2000000;

Для высокого уровня одновременной записи люди используют более тонкие приемы (такие как: ВЫБОР ДЛЯ ОБНОВЛЕНИЯ / NOWAIT, облегченные блокировки, логика повторных попыток и т. Д.).

...