Append бинарное содержимое в колонке BYTEA в базе данных PostgreSQL

Question

Мой случай:

У меня есть некоторые двоичные данные, которые были разбиты на множество частей. Специальная таблица FileParts содержит fileId, partNo и data.

Мне нужно собрать все детали в другой стол MyFilesStorage.

Теперь я буду выбирать между двумя реализациями:

DO $CODE$ 
declare 
    r record; 
begin 
    UPDATE public.MyFilesStorage SET mainFileData = E''::bytea WHERE id = 'e14a26c0-db4b-47e1-8b66-e091fb3ba199'::uuid; 

    for r in (select data 
      from public.FileParts 
      where fileId = '89cb8598-436b-49b3-bb1c-34534c6d068e'::uuid 
      order by partNo) loop 
    UPDATE public.MyFilesStorage SET mainFileData = mainFileData || r.data WHERE id = 'e14a26c0-db4b-47e1-8b66-e091fb3ba199'::uuid; 
    end loop; 

end; 
$CODE$ 

я установить данные, как пустые, то читать части по одному и добавить каждую часть в основную таблицу.

Другой вариант:

DO $CODE$ 
declare 
    r record; 
    p_result bytea; 
begin 
    p_result = E''::bytea; 

    for r in (select data 
      from public.FileParts 
      where fileId = '89cb8598-436b-49b3-bb1c-34534c6d068e'::uuid 
      order by partNo) loop 
    p_result = p_result || r.data; 
    end loop; 

    UPDATE public.MyFilesStorage SET mainFileData = p_result WHERE id = 'e14a26c0-db4b-47e1-8b66-e091fb3ba199'::uuid; 
end; 
$CODE$ 

Здесь я использую переменную TEMP. Во-вторых, гораздо быстрее, но я не знаю, что займет больше памяти? Сначала мне нужна память для загрузки всего файла в ОЗУ, и как насчет первого? Будет ли postgre загружать весь контент здесь: mainFileData = mainFileData || r.data?

Возможно, существует другой способ сделать это, потому что оба варианта: veeeeery slow? В oracle я использую DBMS_LOB.APPEND для этой операции.

Answer 1

Первая версия медленнее, потому что PostgreSQL не делает обновления на месте на уровне хранилища, он создает новую версию строки для каждого UPDATE. Итак, для строки, которая будет идти от 0Mb до 100MB с шагом 10Mb, то, что действительно будет записано на диск, не будет 10x10Mb, а скорее: 10Mb + 20Mb + 30Mb + ... + 90Mb + 100Mb = 550Mb. С другой стороны, потребление памяти будет оставаться низким с объемом памяти не более 10 Мбайт в секунду.

Вторая версия быстрее с записью всего 100 Мб, но ей необходимо выделить 100 Мб в памяти.

Строение таблицы FileParts с упорядоченными кусками, как правило, проще в управлении для большого содержимого, зачем его конвертировать в монолитную структуру?

Answer 2

Ваш подход выглядит правильно, проверьте PostgreSQL manual here.

Вы можете также define your own aggregate, чтобы сделать работу для вас:

CREATE AGGREGATE bytea_add(bytea) 
(
    sfunc = byteacat, 
    stype = bytea, 
    initcond = E'' 
); 

и использование общей SQL, например:

UPDATE public.MyFIlesStorage SET mainFileData = (
    SELECT bytea_add(data) FROM public.FileParts 
    WHERE fileId = '89cb8598-436b-49b3-bb1c-34534c6d068e'::uuid 
    -- ORDER BY partNo -- ORDER BY partNo will not work 
) 
WHERE id = 'e14a26c0-db4b-47e1-8b66-e091fb3ba199'::uuid; 

EDIT:

UPDATE public.MyFilesStorage mfs SET mainFileData = fp.all_data 
    FROM (
    SELECT bytea_add(data) OVER (ORDER BY partNo) AS all_data, 
      rank() OVER (ORDER BY partNo DeSC) AS pos 
     FROM public.FileParts 
    WHERE fileId = '89cb8598-436b-49b3-bb1c-34534c6d068e'::uuid 
) AS fp 
WHERE fp.pos = 1 
    AND mfs.id = 'e14a26c0-db4b-47e1-8b66-e091fb3ba199'::uuid; 

Вы можете проверить вывод внутреннего SQL отдельно.