Почему Postgres так долго возвращает порядковый номер?
-
28-09-2020 - |
Вопрос
У меня есть приложение, которое выполняет массовую загрузку в большую таблицу (100 миллионов строк).Я использую Postgres COPY FROM
возможность загрузки данных из плоского файла.Целевая таблица имеет первичный ключ id
.
Чтобы массовая вставка работала, я создал идентификаторы для каждой строки в файле загрузки, используя:
SELECT nextval('apps_id_seq'::regclass)
FROM "apps"
ORDER BY "apps"."id" ASC
LIMIT 1
К сожалению, я не вижу, чтобы этот запрос занимал более 150 секунд.Это приводит к созданию большого количества резервных копий, поскольку некоторые из этих файлов содержат десятки тысяч строк.
Однако когда я запускаю это в командной строке, я получаю результат в тысячных долях миллисекунды.Вот explain analyze
:
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=0.57..0.64 rows=1 width=4) (actual time=0.016..0.017 rows=1 loops=1)
-> Index Only Scan using apps_pkey on apps (cost=0.57..15886651.40 rows=228128608 width=4) (actual time=0.015..0.015 rows=1 loops=1)
Heap Fetches: 0
Total runtime: 0.030 ms
Что может быть причиной задержки?О задержке сообщили из NewRelic
услуга.
Решение
Я внимательно изучил ваш вопрос, но не могу понять суть описанной вами процедуры.(Вы можете еще немного поработать над описанием.)
Зачем вам генерировать порядковые номера вручную, если Postgres может генерировать их автоматически? Согласно документации:
Если указан список столбцов,
COPY
будет копировать данные только в указанных столбцах в или из файла.Если в таблице есть какие -либо столбцы, которых нет в списке столбцов,COPY FROM
вставить значения по умолчанию для этих столбцов.
Смелый акцент мой.Значение по умолчанию для serial
столбец — это следующий идентификатор из его последовательности.
Вы уверены, что не выполняете много избыточной работы, которая обходится очень дорого?