Re: parallelisme insert/update unnest constraint

Bonjour,

J'ai eu un batch de 40 000 000 INSERTs à faire sur un serveur à 12CPU -
donc un traitement assez proche du tien - et paralléliser sur plusieurs
sessions a permis de passer le temps de 130m à 18m. Après il vaut mieux
laisser un peu de CPUs libres pour le reste des process PG... Cela devrait
être similaire pour des UPDATE (peut être difficile à séparer dans ton
cas?).

Anthony

On Mon, Sep 2, 2019, 15:22 Guillaume Lelarge <guillaume(at)lelarge(dot)info> wrote:

> Le lun. 2 sept. 2019 à 14:17, CRUMEYROLLE Pierre <
> pierre(dot)crumeyrolle(at)c-s(dot)fr> a écrit :
>
>>
>> bonjour
>>
>> je tente de faire un update massif par unnest sur un table de 20
>> millions de ligne,
>> j'ai l'impression que le parallélisme n'est pas vraiment pris en
>> compte dans ce cas
>> les cpu sont à 100% mais pas par alternance , pas de répartition
>> homogène de la charge cpu.
>>
>> les perf en insertion sont bonnes ( 10 millions de ligne en 6 minutes)
>> par contre en update ça rame .
>>
>> malgré un postgresl.conf adapté à une cible multi cpu (12)
>> max_worker_processes = 12
>> max_parallel_workers_per_gather = 6
>> max_parallel_workers = 12
>> version => postgresl 11.4
>>
>> ma question : peut t'on faire du parallélisme sur de l'insert ou de
>> l'update avec ou sans contraintes defferées ?
>> (j'ai cru comprendre que parallélisation => multi transaction => pas
>> de constraintes )
>>
>> ce que je fais dans une proc stock tentative update massif par unnest
>> ( mais c'est peut être pas la bonne piste ? )
>>
>> -- pk defferable
>> SET CONSTRAINTS t_test_pkey DEFERRED;
>>
>> UPDATE T_test SET data = jsonb_set(T.datanew::jsonb, '{id}',to_jsonb(
>> 'provider ' || (T.id::text))) , created_at = T.created_at::timestamp
>> FROM (select * from
>> unnest(tabi) as id,
>> unnest(tabp) as provider,
>> unnest(tabdate) as created_at,
>> unnest(tab) as datanew) T
>> where T_test.id=cast(T.id as int);
>> COMMIT;
>>
>>
> PostgreSQL ne parallélise pas les requêtes en écriture (comme INSERT ou
> UPDATE). Le seul moyen est de paralléliser au niveau applicatif (donc
> plusieurs connexions, chacune faisant ses INSERT/UPDATE).
>
>
> --
> Guillaume.
>