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 1sp34I-00Fy3E-Au for pgsql-general@arkaria.postgresql.org; Fri, 13 Sep 2024 09:58:23 +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 1sp34G-00HVkO-GW for pgsql-general@arkaria.postgresql.org; Fri, 13 Sep 2024 09:58:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sp34G-00HVkG-27 for pgsql-general@lists.postgresql.org; Fri, 13 Sep 2024 09:58:20 +0000 Received: from mail-oo1-xc35.google.com ([2607:f8b0:4864:20::c35]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sp34D-000xpZ-7B for pgsql-general@lists.postgresql.org; Fri, 13 Sep 2024 09:58:19 +0000 Received: by mail-oo1-xc35.google.com with SMTP id 006d021491bc7-5e1c63c9822so1118669eaf.0 for ; Fri, 13 Sep 2024 02:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726221497; x=1726826297; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7TDKp/4LiOgsKOiz0sKk8B+Fx08HcIccEUgVQer+TMk=; b=D6gAxTXBv5CB6SX3e36h+kVBVWCL6TneUaDsSpo7thhyc8aOT69DDJAPi189IVu3sY jEBQustlKCtCRyDwacjRzFuXNuhl33GpTWqTsCjg4iUi+xEWq05DqqIq2y8FgWI3FfUu fwQcnSzsqCDfCmgDS4qFjLYb11L4GpXtMdWcct1iadXngWuJZrirppNgERIFaXC6NeyT 7sKwiQP1kxTC/IHAlVd6c5oOFcopdSNQW0gwLGXpSkyNpFlyPHhyPNnbwb2vYcgr0Xtq QFb6Y3vL+dMHgtjYfMkKkhtnFsDSsp+1lGn6oSqz7Mshpkyk8KpX+8tUZNzG9VrkZzxH Rv2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726221497; x=1726826297; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7TDKp/4LiOgsKOiz0sKk8B+Fx08HcIccEUgVQer+TMk=; b=WiWFxR1GGCnEx/cQzrlE8UBDSRS7tzpDhPaOa5V2itzn2jZWffWi6qLcBAK1nVNFyp xSRYgGAnGh3KfIeFhuQaIc/cL/gYvUvsaxewKVu5mhsaK6/IiGuNgIurzP0rLJJtph8K EGpYiUgOnE5wBhMA6ZAk7EfICwUeCo77SRw3qlsmVvI1qTQWfVLdcNIjhVIxaFPjCjuh 84f2n/+vd9/+k2tVkZmFsQKrxal9Wm+HD3B5ejyrOmvxtgbmH7Jd9F8wNoT+y7gtWEu1 xnMla61i3ve7YANZn6Q6KjDOXDapxSV7wZBBf9qKI1vXm4IUuMn71YI8pQ9khwddYluV Z2sg== X-Gm-Message-State: AOJu0YytdU9sbTJzrLTvXvjE643q3Ug/wzYhC9md4AMSRrnPpU3FSrQq mdhqe4XfoVqHcAJFbfNitoaQONW9HqZVnD/vSXECRXyt0zujwTHZO+kSwp72pU8zau8nMkkeYPe ytHs62jyNFo6kWIk7yBOO537+/N9GAYY= X-Google-Smtp-Source: AGHT+IHtB+HK7GPm8CkfeA1vwBUp9/5m10C7pmYer6+wstmwudJdFknKUSgD/CvjrxKp+Ee6wNGzxf90SDdrsWFRgYo= X-Received: by 2002:a05:6870:d181:b0:268:880c:9de3 with SMTP id 586e51a60fabf-27c3f255fa5mr3988523fac.14.1726221496813; Fri, 13 Sep 2024 02:58:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Juan Rodrigo Alejandro Burgos Mella Date: Fri, 13 Sep 2024 06:58:05 -0300 Message-ID: Subject: Re: Manual query vs trigger during data load To: yudhi s Cc: pgsql-general Content-Type: multipart/alternative; boundary="0000000000001f10590621fd43b4" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000001f10590621fd43b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I find it unlikely that the trigger will work properly, since the reserved fields of the OLD subset have no value in an INSERT Atte JRBN El vie, 13 de sept de 2024, 04:32, yudhi s escribi=C3=B3: > Hello All, > > We are having a table which is going to be inserted with 100's of million= s > of rows each day. And we now want to have a requirement in which we need = to > do some transformation/lookup logic built on top of a few of the input bi= nd > values , while inserting the data. So I wanted to understand ,is it > possible to do it along with the INSERT query or is it better to have a > trigger created for the same? > > For. e.g Below is the current Insert query used in the Java code. We want > to fetch the value for "column2" from a lookup table rather than directly > inserting as it's coming from the customer side. So I am thinking of a > trigger like below. But at the same time I also want to compare the > performance of a normal way of doing the lookup vs having it performed > using triggers. > > So one way i am thinking is first fetching the value of the "column2" fro= m > reference_tab1 using a separate "select query" in Java code itself, and > then passing that to the below insert query, but i think that will increa= se > the response time as that will be a separate DB call. > > 1)So, is there a way I can do it directly using the single INSERT query > itself without additional SELECT query? And then will try to compare that > with the trigger based approach. > 2)Additionally , if this decision will impact a batch insert approach. > i.e. say , in case of trigger , will the batch insert fail because > trigger will force it to make it row by row? > > INSERT INTO tab_part1 (column1, column2, column3, column4, column5, > part_date) > VALUES (:v_col1, :v_col2, :v_col3, :v_col3, :v_col4,:v_col5, > CURRENT_DATE); > > CREATE OR REPLACE FUNCTION trg_func_populate_column2() RETURNS TRIGGER AS > $$ > BEGIN > -- Fetch reference value and populate column2 > NEW.column2 :=3D (SELECT lookup_key FROM reference_tab1 WHERE lookup_= key > =3D old.column2); > RETURN NEW; > END; > $$ LANGUAGE plpgsql; > > Regards > Yudhi > --0000000000001f10590621fd43b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello, I find it unlikely that the trigger will work properl= y, since the reserved fields of the OLD subset have no value in an INSERT

Atte
JRBN


El vie= , 13 de sept de 2024, 04:32, yudhi s <learnerdatabase99@gmail.com> escribi=C3=B3:
Hello All,

We are hav= ing a table which is going to be inserted with 100's of millions of row= s each day. And we now want to have a requirement in which we need to do so= me transformation/lookup logic built on top of a few of the input bind valu= es , while inserting the data. So I wanted to understand ,is it possible to= do it along with the INSERT query or is it better to have a trigger create= d for the same?

For. e.g Below is the current Insert query used in t= he Java code. We want to fetch the value for "column2" from a loo= kup table rather than directly inserting as it's coming from the custom= er side. So I am thinking of a trigger like below. But at the same time I a= lso want to compare the performance of a normal way of doing the lookup vs = having it performed using triggers.

So one way i am thinking is fir= st fetching the value of the "column2" from reference_tab1 using = a separate "select query" in Java code itself, =C2=A0and then pas= sing that to the below insert query, but i think that will increase the res= ponse time as that will be a separate DB call.

1)S= o,=C2=A0=C2=A0is there a way I can do it directly using the single INSERT q= uery itself without additional SELECT query? And then will try to compare t= hat with the trigger based approach.
2)Additionally , if this decision w= ill impact a batch insert approach. i.e. say , in case of trigger , will th= e batch insert fail because trigger=C2=A0will force it to make it row by ro= w?

INSERT INTO tab_part1 (column1, column2, column3, column4, column= 5, part_date)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 VALUES (:v_col1, :v_col2, :v_c= ol3, :v_col3, :v_col4,:v_col5, CURRENT_DATE);

CREATE OR REPLACE FUNC= TION trg_func_populate_column2() RETURNS TRIGGER AS $$
BEGIN
=C2=A0 = =C2=A0 -- Fetch reference value and populate column2
=C2=A0 =C2=A0 NEW.c= olumn2 :=3D (SELECT lookup_key FROM reference_tab1 WHERE lookup_key =3D old= .column2);
=C2=A0 =C2=A0 RETURN NEW;
END;
$$ LANGUAGE plpgsql;
=

Regards
Yudhi
--0000000000001f10590621fd43b4--