Обсуждение: А вот кстати, как быстро заполнить столбик?

Дано:

1. таблица 87 млн записей
2. добавляем столбик "c" TEXT DEFAULT 'abc';
 - DEFAULT для новых записей, поле NULL
3. строим индекс по "id", WHERE "c" IS NULL

затем в цикле на perl пишем программу вызывающую запрос

WITH "lst" AS (
    SELECT
        "id"
    FROM
        "table"
    WHERE
        "c" IS NULL
    ORDER BY
        "id" DESC
    LIMIT
        100
)
UPDATE
    "table"
SET
    "c" = "d"
FROM
    "lst"
WHERE
    "table"."id" = "lst"."id";


но такой подход по расчетам показывает что будет заполнять 87 млн
записей где-то 14 с гаком дней.

варьируя LIMIT 1-1000 можно очень немного варьировать скоростью.
типа 14 дней может стать 18 или 12-ю.


Есть вариант неблокируя БД заполнить поле более быстро?

вот CREATE INDEX CONCURRENTLY по этой таблице строится за 5 минут
примерно.
я понимаю что заполнение столбика - запись, но 14 дней очень уж много.

есть идеи как быстрее сделать?

--

. ''`.            Dmitry E. Oboukhov <unera@debian.org>
: :’  :
`. `~’               GPG key: 4096R/08EEA756 2014-08-30
  `- 71ED ACFC 6801 0DD9 1AD1  9B86 8D1F 969A 08EE A756

Привет
Такой update по понятной причине будет сильно замедляться пока не придёт vacuum. А чтобы замедляться пока не придёт
vacuum- надо не ходить повторно по обработанным записям.
 

Эффективнее всего - пройти запросами по диапазону ctid от начала до конца таблицы.
Проще всего и при этом без замедления от удалённый строк - по диапазонам id: UPDATE "table" SET "c" = "d" WHERE id >= 0
andid < 5000 и сдвигать диапазон на каждой итерации.
 
На различное заполнение пачки id при этом банально забить.

Лучше всё-таки давать между итерациями время поработать автовакууму, тем самым замедляя миграцию, но не давать табличке
распухнутьвдвое. Ну или сразу заложить запуск pgcompacttable или pg_repack после миграции.
 

Сергей