Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sr9kv-00Fksa-0t for pgsql-general@arkaria.postgresql.org; Thu, 19 Sep 2024 05:31:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sr9kt-004Lnv-N4 for pgsql-general@arkaria.postgresql.org; Thu, 19 Sep 2024 05:31:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sr9kt-004LXG-7M for pgsql-general@lists.postgresql.org; Thu, 19 Sep 2024 05:31:03 +0000 Received: from mail-yb1-xb2a.google.com ([2607:f8b0:4864:20::b2a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sr9kq-001v2i-Kq for pgsql-general@lists.postgresql.org; Thu, 19 Sep 2024 05:31:01 +0000 Received: by mail-yb1-xb2a.google.com with SMTP id 3f1490d57ef6-e1a7e54b898so376792276.2 for ; Wed, 18 Sep 2024 22:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726723860; x=1727328660; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=0F2n2fFA8daA9X3hqeqmYiAE5ZHG6YRUQwe7btJKb8U=; b=aXL1+RB1k60hDCFYsFsZRr+x3AwmuRR5YgqnFbDssXDbR/dNChzUksvKc6bElBhq1l BU5dPPlx85IFucFXOLSfYJ9cHrqi/iTgldnL6Ap4nx+c6BVb3EwiMBgbeDQfSW7kMoYG vz0vGdOVX2cPbxig6ar0Yg47zNUhIR/wzwExZbDbeIiGPzQ6aw0fhnJeVxtNCLWz0hLa p4V2afGWM56RCMb1/7lCc/GQCEoYXL2jfGAbgyt/3GBdxNWjCgAwvZqNDGof7uLgo68o wUWRDOQs1TYyxp71AomTrqXCp3Zr3w+ecr0brObecdks8yqlfFsMFT7EUfF6YulmLqhS GEPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726723860; x=1727328660; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=0F2n2fFA8daA9X3hqeqmYiAE5ZHG6YRUQwe7btJKb8U=; b=vY/Ab3sRBtR/k3yB83V85191mZnBkHLtO2x88iLby9Ne6ktP8JgMjL6lzWGUPyrfEr bac/eGirLtvI2BwvEu36oI5Q/gioV3TvlfXRYin6/MRa2tDw6/DGNocYV8EGYvIE28u9 PkB6j1bgx9KKYlEfVzDbkFNFom0yvaT0/VFX3CYbG7I0vfixn3d3/bdkNQjGfmCrycl2 ECOHucaqN5yvX89o+lAP4vB2ic0087qKK8GzSsz6OCf7so1uI6USsNGPWXsu1YmMAmBi 5talDhsYYTS+ImqHu6GGJLemks/tKHWtBWmTPvHR6+7qgk8nJdUpeTVv0KeYwQha2dMt vRow== X-Gm-Message-State: AOJu0Ywm6C0zBSOxfvlb9SRvajzcsBDin2jAqaR0ZF0NkMwXkOKkZfnA jXNX+UPu2Gc7oOfB9GqRgnp3pbzozG17wOD8BAJkbYRbX7RfFapwyzqKOvrG/XSa+Lw6dXjNm8Y os+hSIY0JRjR1Aa9kXDHp/NMEIy7VXZDq X-Google-Smtp-Source: AGHT+IF8mGXALY3ksKr6ZPAfTuMm3KQEfMQ40MUisojO+20CYHEcQvN37E6B5Xl5/squcyQ+vjbULuMBNV713RwBGKw= X-Received: by 2002:a05:6902:2212:b0:e1d:94a7:4633 with SMTP id 3f1490d57ef6-e1d9dba84bfmr17261193276.22.1726723859757; Wed, 18 Sep 2024 22:30:59 -0700 (PDT) MIME-Version: 1.0 From: Lok P Date: Thu, 19 Sep 2024 11:00:47 +0530 Message-ID: Subject: How batch processing works To: pgsql-general Content-Type: multipart/alternative; boundary="00000000000049441c0622723a86" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000049441c0622723a86 Content-Type: text/plain; charset="UTF-8" Hello, Saw multiple threads around the same , so I want some clarification. As we know row by row is slow by slow processing , so in heavy write systems(say the client app is in Java) , people asked to do DMLS in batches rather in a row by row fashion to minimize the chatting or context switches between database and client which is resource intensive. What I understand is that , a true batch processing means the client has to collect all the input bind values and prepare the insert statement and submit to the database at oneshot and then commit. What it means actually and if we divide the option as below, which method truly does batch processing or there exists some other method for doing the batch processing considering postgres as backend database? I understand, the first method below is truly a row by row processing in which context switches happen between client and database with each row, whereas the second method is just batching the commits but not a true batch processing as it will do the same amount of context switching between the database and client. But regarding the third and fourth method, will both execute in a similar fashion in the database with the same number of context switches? If any other better method exists to do these inserts in batches? Appreciate your guidance. CREATE TABLE parent_table ( id SERIAL PRIMARY KEY, name TEXT ); CREATE TABLE child_table ( id SERIAL PRIMARY KEY, parent_id INT REFERENCES parent_table(id), value TEXT ); Method-1 insert into parent_table values(1,'a'); commit; insert into parent_table values(2,'a'); commit; insert into child_table values(1,1,'a'); Commit; insert into child_table values(1,2,'a'); commit; VS Method-2 insert into parent_table values(1,'a'); insert into parent_table values(2,'a'); insert into child_table values(1,1,'a'); insert into child_table values(1,2,'a'); Commit; VS Method-3 with a as ( insert into parent_table values(1,'a') ) , a1 as (insert into parent_table values(2,'a') ) , b as (insert into child_table values(1,1,'a') ) , b1 as (insert into child_table values(1,2,'a') ) select; commit; Method-4 INSERT INTO parent_table VALUES (1, 'a'), (2, 'a'); INSERT INTO child_table VALUES (1,1, 'a'), (1,2, 'a'); commit; Regards Lok --00000000000049441c0622723a86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
Saw multiple threads around the same , so I wan= t some clarification. As we know row by row is slow by slow processing , so= in heavy write systems(say the client app is in Java) , people asked to do= DMLS in batches rather in a row by row fashion to minimize the chatting or= context switches between database and client which is resource intensive. = What I understand is that , a true batch processing means the client has to= collect all the input bind values and =C2=A0prepare the insert statement a= nd submit to the database at oneshot and then commit.

What it means= actually and if we divide the option as below, which method truly does bat= ch processing or there exists some other method for doing the batch process= ing considering postgres as backend database?

I understand, the firs= t method below is truly a row by row processing in which context switches h= appen between client and database with each row, whereas the second method = is just batching the commits but not a true batch processing as it will do = the same amount of context switching between the database and client. But r= egarding the third and fourth method, will both execute in a similar fashio= n in the database with the same number of context switches? If any other be= tter method exists to do these inserts in batches? Appreciate your guidance= .


CREATE TABLE parent_table (
=C2=A0 =C2=A0 id SERIAL PRIMARY= KEY,
=C2=A0 =C2=A0 name TEXT
);

CREATE TABLE child_table (=C2=A0 =C2=A0 id SERIAL PRIMARY KEY,
=C2=A0 =C2=A0 parent_id INT REFERE= NCES parent_table(id),
=C2=A0 =C2=A0 value TEXT
);


Method-= 1

insert into parent_table values(1,'a');
commit;
ins= ert into parent_table values(2,'a');
commit;
insert into chi= ld_table values(1,1,'a');
Commit;
insert into child_table va= lues(1,2,'a');
commit;

VS

Method-2

insert= into parent_table values(1,'a');
insert into parent_table valu= es(2,'a');
insert into child_table values(1,1,'a');
= insert into child_table values(1,2,'a'); =C2=A0
Commit;

V= S

Method-3

with
=C2=A0a as ( insert into parent_table valu= es(1,'a') =C2=A0)
, a1 as (insert into parent_table values(2,= 9;a') )
, b as (insert into child_table values(1,1,'a') =C2= =A0)
=C2=A0, b1 as =C2=A0(insert into child_table values(1,2,'a'= ) =C2=A0)
select;
commit;

Method-4

INSERT INTO parent_t= able VALUES =C2=A0(1, 'a'), (2, 'a');
INSERT INTO child_= table VALUES =C2=A0 (1,1, 'a'), (1,2, 'a');
commit;
<= /div>

Regards
Lok
--00000000000049441c0622723a86--