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 1spC1w-00HJXT-O5 for pgsql-general@arkaria.postgresql.org; Fri, 13 Sep 2024 19:32:33 +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 1spC1v-00ANGz-MW for pgsql-general@arkaria.postgresql.org; Fri, 13 Sep 2024 19:32:31 +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 1spC1v-00ANFw-Ar for pgsql-general@lists.postgresql.org; Fri, 13 Sep 2024 19:32:31 +0000 Received: from mail-qk1-x72b.google.com ([2607:f8b0:4864:20::72b]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1spC1r-0012KX-Lt for pgsql-general@lists.postgresql.org; Fri, 13 Sep 2024 19:32:30 +0000 Received: by mail-qk1-x72b.google.com with SMTP id af79cd13be357-7a99e8d5df1so122320485a.2 for ; Fri, 13 Sep 2024 12:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726255947; x=1726860747; 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=QS8LCr/xnugxHiBQeodIdNuCc6fv94xnM0FI5uQ8KWA=; b=bjevij3NltUZL7ebBihdH7506G8BvXROthUVPWPVibBOGfpuaLabTMYUX+9XE5Nuon dEHdgq+Kcm39PQc7wLiNrDRznECZhQ8D0iQTqvAOcx0Eb8VTgPCWwF9RjYGhm4M3+ASb f3cZLAt1aUFTfdWDNw0hPU7Nxwnu1KLhyi17CQ/jDSNcCcuLkIQcnl3cr1NiOILbk55d TjJ/GmcHueIlzYwIA5T2yNCuHkHcKyMooLnaK6rEewesvGwHUL/x4+Ftmq8DBkztvm8f Qizd7gRW6C2baUgpB3HdkPSr4y2z83QlwozebnZGNrL9fGIg55xvQXYTzmP7IrTW9ef1 jkfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726255947; x=1726860747; 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=QS8LCr/xnugxHiBQeodIdNuCc6fv94xnM0FI5uQ8KWA=; b=ruV8Hwjrr7duWAVnIutzoYKIuPl1K1qNCgcSthRQf7TAkYJEhFPPyVex5JTxJP4ThL CVh9cC7gfOjrhhJshZH8yOymtUHzGaB91q2dqROef/w9Mq4dPDqlM8ZPuHnCdNCYqQEc w5Ad/aL53YetzxZhK9CtcgiIEOHc54wX4vASPYWKFkr6szx2BpMplbXKISX0xzgE2HRg y07H0bTT1JgisNQaVi3nmrz+M1ZMVXHp2SGJGti1UoC1uh2ecAedo04IaaPa9Nmg8TL9 sieCcEY28KQdGG8DjyyPafbOiHilHHk0vF8b86uoihbR5QlY0GR8JINetZr263hnznuY V3LQ== X-Gm-Message-State: AOJu0YwxzX48DeQkw+6fHqgwybRa1H1K+wJI6FRcmbRRFCfsYIvNsvn3 bOxZD9CZynBK4/awK86lPCTIIIhjs1D4tNtx6CfWDs3kt3b16AwYSeS47Oy3WmBhCbXXwrrw3P4 ApaAE7xqs1h2KNBJ94KNSrR6lCaNuI6qR X-Google-Smtp-Source: AGHT+IF5roP9HWLc6SSkT3nOz27S4/ue/oTOa9dWRyHnxfylqoil9xybOxor6ZqPDQPPhXbpMzZv78ILhrPITlQuUOg= X-Received: by 2002:a05:6871:ca08:b0:278:1b05:eda9 with SMTP id 586e51a60fabf-27c689141b6mr2666601fac.17.1726255500916; Fri, 13 Sep 2024 12:25:00 -0700 (PDT) MIME-Version: 1.0 References: <67f2a664-b480-40ea-892d-2ab2147ad390@aklaver.com> In-Reply-To: <67f2a664-b480-40ea-892d-2ab2147ad390@aklaver.com> From: yudhi s Date: Sat, 14 Sep 2024 00:54:49 +0530 Message-ID: Subject: Re: Manual query vs trigger during data load To: Adrian Klaver , Juan Rodrigo Alejandro Burgos Mella , Rob Sargent Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000ec82650622052d15" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000ec82650622052d15 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 13, 2024 at 8:27=E2=80=AFPM Adrian Klaver wrote: > On 9/13/24 07:50, Adrian Klaver wrote: > > On 9/13/24 02:58, Juan Rodrigo Alejandro Burgos Mella wrote: > >> 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 > > > > I'm not seeing that the OP is asking for OLD.* values, they are just > > looking to include the result of a lookup on another table in the INSER= T. > > My mistake I see the OLD reference now. > > > > My mistake.The trigger was supposed to use "new.col2" and fetch the corresponding lookup value from the lookup table and insert that value to the target table. Now my question was ,in such a situation , the trigger will work fine , but is that the optimal way of doing ? Or should we convert the query someway such that the lookup table can be queried along with the INSERT at one shot from the database with a single DB call? And is it true that the trigger on the target table will suppress the batch insert and make it row by row, even if we call it in a batch fashion? As "thiemo" mentioned , it can be done as below method, but if we have multiple lookup tables to be populated for multiple columns , then , how can the INSERT query be tweaked to cater the need here? And I understand , the lookup table can be cached in Java and refreshed at a certain point in time, but I was trying to understand if this can be doable by directly querying the database, considering the lookup tables are having large data sets in them. Insert into tab1 (val1, val2) Select valA, valB From tab2 Where valC =3D :param1 --000000000000ec82650622052d15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Sep 13, 2024 at 8:27=E2=80=AFPM A= drian Klaver <adrian.klaver= @aklaver.com> wrote:
On 9/13/24 07:50, Adrian Klaver wrote:
> On 9/13/24 02:58, Juan Rodrigo Alejandro Burgos Mella wrote:
>> Hello, I find it unlikely that the trigger will work properly, sin= ce
>> the reserved fields of the OLD subset have no value in an INSERT >
> I'm not seeing that the OP is asking for OLD.* values, they are ju= st
> looking to include the result of a lookup on another table in the INSE= RT.

My mistake I see the OLD reference now.

>

My mistake.The trigger was suppose= d=C2=A0to use "new.col2" and fetch the corresponding lookup value= from the lookup table and insert that value to the target table.

Now my question was ,in such a situation , the trigger=C2= =A0will work fine , but is that the optimal way of doing ? Or should we con= vert the query someway such that the lookup table can be queried along with= the INSERT at one shot from the database with a single DB call? And is it = true that the=C2=A0trigger on the target table will suppress the batch inse= rt and make it row by row, even if we call it in a batch fashion?

As "thiemo" mentioned , it can be done as below m= ethod, but if we have multiple=C2=A0lookup tables to be populated for multi= ple columns , then , how can the INSERT query be tweaked to cater the need = here? And I understand , the lookup table can be cached in Java and refresh= ed at a certain point in time, but I was trying to understand if this can b= e doable by directly querying the database, considering the lookup tables a= re having large data sets in them.

Insert into tab1 (val1, val2)=
Sel= ect valA, valB
From tab2
Where valC =3D :param1
=C2=A0
--000000000000ec82650622052d15--