Re: parallelisme insert/update unnest constraint

Anthony Nowocien <[email protected]> Mon, 2 Sep 2019 17:02:59 +0200
Newsgroups gmane.comp.db.postgresql.french
Message-ID <CAH5RRoNHKPOqHHpLoB9tA2o8PNiNp0=GLEOaqUQH5qXy4nHArA@mail.gmail.com>
--00000000000042ee4605919345e7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Bonjour,

J'ai eu un batch de 40 000 000 INSERTs =C3=A0 faire sur un serveur =C3=A0 1=
2CPU -
donc un traitement assez proche du tien - et parall=C3=A9liser sur plusieur=
s
sessions a permis de passer le temps de 130m =C3=A0 18m. Apr=C3=A8s il vaut=
 mieux
laisser un peu de CPUs libres pour le reste des process PG... Cela devrait
=C3=AAtre similaire pour des UPDATE (peut =C3=AAtre difficile =C3=A0 s=C3=
=A9parer dans ton
cas?).

Anthony


On Mon, Sep 2, 2019, 15:22 Guillaume Lelarge <[email protected]> wrote=
:

> Le lun. 2 sept. 2019 =C3=A0 14:17, CRUMEYROLLE Pierre <
> [email protected]> a =C3=A9crit :
>
>>
>> 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=C3=A9lisme n'est pas vraiment pris en
>> compte dans ce cas
>> les cpu sont =C3=A0 100% mais pas par alternance , pas de r=C3=A9partiti=
on
>> homog=C3=A8ne de la charge cpu.
>>
>> les perf en insertion sont bonnes ( 10 millions de ligne en 6 minutes)
>> par contre en update =C3=A7a rame .
>>
>> malgr=C3=A9 un postgresl.conf adapt=C3=A9 =C3=A0 une cible multi cpu (12=
)
>> max_worker_processes =3D 12
>> max_parallel_workers_per_gather =3D 6
>> max_parallel_workers =3D 12
>> version =3D> postgresl 11.4
>>
>> ma question : peut t'on faire du parall=C3=A9lisme sur de l'insert ou de
>> l'update avec ou sans contraintes deffer=C3=A9es ?
>> (j'ai cru comprendre que parall=C3=A9lisation =3D> multi transaction =3D=
> pas
>> de constraintes  )
>>
>> ce que je fais dans une proc stock tentative update massif par unnest
>> ( mais c'est peut =C3=AAtre pas la bonne piste ? )
>>
>> -- pk defferable
>> SET CONSTRAINTS t_test_pkey DEFERRED;
>>
>> UPDATE T_test SET data =3D jsonb_set(T.datanew::jsonb, '{id}',to_jsonb(
>> 'provider ' || (T.id::text)))  , created_at =3D 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=3Dcast(T.id as int);
>>    COMMIT;
>>
>>
> PostgreSQL ne parall=C3=A9lise pas les requ=C3=AAtes en =C3=A9criture (co=
mme INSERT ou
> UPDATE). Le seul moyen est de parall=C3=A9liser au niveau applicatif (don=
c
> plusieurs connexions, chacune faisant ses INSERT/UPDATE).
>
>
> --
> Guillaume.
>

--00000000000042ee4605919345e7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Bonjour,</div><div dir=3D"auto"><br><div dir=3D"auto=
">J&#39;ai eu un batch de 40 000 000 INSERTs =C3=A0 faire sur un serveur =
=C3=A0 12CPU - donc un traitement assez proche du tien - et parall=C3=A9lis=
er sur plusieurs sessions a permis de passer le temps de 130m =C3=A0 18m. A=
pr=C3=A8s il vaut mieux laisser un peu de CPUs libres pour le reste des pro=
cess PG... Cela devrait =C3=AAtre similaire pour des UPDATE (peut =C3=AAtre=
 difficile =C3=A0 s=C3=A9parer dans ton cas?).</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">Anthony</div><br><br><div class=3D"gmail_quote" dir=
=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Sep 2, 2019, 15:22 =
Guillaume Lelarge &lt;<a href=3D"mailto:[email protected]">guillaume@l=
elarge.info</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">L=
e=C2=A0lun. 2 sept. 2019 =C3=A0=C2=A014:17, CRUMEYROLLE Pierre &lt;<a href=
=3D"mailto:[email protected]" target=3D"_blank" rel=3D"noreferrer">=
[email protected]</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><br>
bonjour<br>
<br>
je tente de faire un update massif par unnest sur un table de 20=C2=A0 <br>
millions de ligne,<br>
j&#39;ai l&#39;impression que le parall=C3=A9lisme n&#39;est pas vraiment p=
ris en=C2=A0 <br>
compte dans ce cas<br>
les cpu sont =C3=A0 100% mais pas par alternance , pas de r=C3=A9partition=
=C2=A0 <br>
homog=C3=A8ne de la charge cpu.<br>
<br>
les perf en insertion sont bonnes ( 10 millions de ligne en 6 minutes)=C2=
=A0 <br>
par contre en update =C3=A7a rame .<br>
<br>
malgr=C3=A9 un postgresl.conf adapt=C3=A9 =C3=A0 une cible multi cpu (12)<b=
r>
max_worker_processes =3D 12<br>
max_parallel_workers_per_gather =3D 6<br>
max_parallel_workers =3D 12<br>
version =3D&gt; postgresl 11.4<br>
<br>
ma question : peut t&#39;on faire du parall=C3=A9lisme sur de l&#39;insert =
ou de=C2=A0 <br>
l&#39;update avec ou sans contraintes deffer=C3=A9es ?<br>
(j&#39;ai cru comprendre que parall=C3=A9lisation =3D&gt; multi transaction=
 =3D&gt; pas=C2=A0 <br>
de constraintes=C2=A0 )<br>
<br>
ce que je fais dans une proc stock tentative update massif par unnest=C2=A0=
 <br>
( mais c&#39;est peut =C3=AAtre pas la bonne piste ? )<br>
<br>
-- pk defferable<br>
SET CONSTRAINTS t_test_pkey DEFERRED;<br>
<br>
UPDATE T_test SET data =3D jsonb_set(T.datanew::jsonb, &#39;{id}&#39;,to_js=
onb(=C2=A0 <br>
&#39;provider &#39; || (T.id::text)))=C2=A0 , created_at =3D T.created_at::=
timestamp<br>
=C2=A0 =C2=A0 =C2=A0FROM (select * from<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 unnest(tabi) as id,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 unnest(tabp) as provider,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 unnest(tabdate) as created_at,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 unnest(tab) as datanew) T<br>
=C2=A0 =C2=A0 =C2=A0where T_test.id=3Dcast(T.id as int);<br>
=C2=A0 =C2=A0COMMIT;<br>
<br></blockquote><div><br></div><div>PostgreSQL ne parall=C3=A9lise pas les=
 requ=C3=AAtes en =C3=A9criture (comme INSERT ou UPDATE). Le seul moyen est=
 de parall=C3=A9liser au niveau applicatif (donc plusieurs connexions, chac=
une faisant ses INSERT/UPDATE).<br></div></div><div><br></div><div><br></di=
v>-- <br><div dir=3D"ltr" class=3D"m_-6771055077344270244gmail_signature"><=
div dir=3D"ltr"><div><div dir=3D"ltr"><div>Guillaume.<br></div></div></div>=
</div></div></div>
</blockquote></div></div></div>

--00000000000042ee4605919345e7--