Re: parallelisme insert/update unnest constraint

je cherche à benchmarker les perfo de postgresql sur du chargement
massive par lots via unnest mais avec du jsonb
en 6 minutes je lui fait avaler 20 millions de lignes 33G de jsonb
procedure stockée + unnest table simple id date jsonb

Anthony Nowocien <anowocien(at)gmail(dot)com> a écrit :

> 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.
>>