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 1slpm8-001Sh6-Hq for pgsql-general@arkaria.postgresql.org; Wed, 04 Sep 2024 13:10:20 +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 1slpm6-009bLe-UE for pgsql-general@arkaria.postgresql.org; Wed, 04 Sep 2024 13:10:19 +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 1slpm6-009bKm-Fd for pgsql-general@lists.postgresql.org; Wed, 04 Sep 2024 13:10:18 +0000 Received: from mail-qv1-xf2c.google.com ([2607:f8b0:4864:20::f2c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1slpm4-00077Z-9c for pgsql-general@lists.postgresql.org; Wed, 04 Sep 2024 13:10:17 +0000 Received: by mail-qv1-xf2c.google.com with SMTP id 6a1803df08f44-6c35357cdacso22433956d6.0 for ; Wed, 04 Sep 2024 06:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725455415; x=1726060215; 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=doI5mwfmjX9YYfmW2T0fVdeI2xq3qB/5Hfhj3B/Ufpo=; b=QhmMOVjefXYUi9sqwooGSNo5oFHxsBdx53iKcnI12R2cli8/Tl386ItvtOewxOuZEe IA3Ghrn9GDw9YgIUNxlkjbsEmLUzMjmS/AyBezOQBTGzDi3o4oIy9KI4JwzUrAiVuaHr /UtsonwpWCmsi2hkYHRgdJY9A3lH9VDzVEGmvXY3drMrebjgdYFCnvApjTi3cZ0F7stE yhWI406YmRurCneQ1E+NcdLuTbHpTtUZYftMFG1WsrO0Ijn92pbqI3hnPhCpoaSU1pNq DrhhK/8cKdE+NiVSElQ5qlq0lc4T4CcEFM8im106B3ggdqxeRzej6SyS/mkx6SRmfEmB nFsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725455415; x=1726060215; 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=doI5mwfmjX9YYfmW2T0fVdeI2xq3qB/5Hfhj3B/Ufpo=; b=R35xpXutx8buEo172qiJY7Yw3m5qq1gfQWy9WVS9hFdRiMr1/9jlVedUqbF4jsQv8L 81zqs0usKCQhHYo5noHPyUcR+fn/Knp1Jmn4Oq+N6LJ288xtALtIoGdZu99V00ohcNTh ZQJRA+Ruw9VNzzzpLsLNJo2u7iaYnt7XuCrBv9eYW07NPMMr/bE7KNiiQnPdXtmEYhlz 9kwIdjyD2/4j8l3vyMl9yPXnK48qry+6OXHfJgZK+6gsRr77KGpg9neoWtgiNQolcPuP HYSAQJofznwL0JF45oDEaaNJ67ilxgpT2EhLLPc7LyEA3JQOxQzev78jbYSOpsp9NB9d ZGCA== X-Gm-Message-State: AOJu0Yy7sCluNn3UcAOuAjwHdiOs5fcQeBQ4DWTk3aoRkvZTQE2/+O6Y 0pX27iIEvlt+IN/fEhAn/kNVkxSM+HGMYve9MM655Ouy3AK/jLHELR+GIY/xIb9qKjN3VHI5sue 3nzGxEnjxD+0c5HK14ZyThiJlxvKJxA== X-Google-Smtp-Source: AGHT+IFYHK1ssTJPLwSJQiEmJeCE7NzCLKyMoAj7jog4eL+LOi9ClbsXtKVJXk0DetbzChuxgt/4Pdr38o1hXHDtGNI= X-Received: by 2002:a05:6214:43c3:b0:6c3:67d5:a91 with SMTP id 6a1803df08f44-6c367d50dc4mr106770156d6.24.1725455415162; Wed, 04 Sep 2024 06:10:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: yudhi s Date: Wed, 4 Sep 2024 18:40:04 +0530 Message-ID: Subject: Re: question on audit columns To: Muhammad Usman Khan Cc: pgsql-general Content-Type: multipart/alternative; boundary="00000000000018c1c006214ae5aa" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000018c1c006214ae5aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 4, 2024 at 6:29=E2=80=AFPM Muhammad Usman Khan wrote: > Hi, > > In your scenario, triggers can add some overhead since they require extra > processing after each update operation. Considering the size of your tabl= e > and the high transaction volume, you need to observe that this might > significantly affect performance. > > > > > On Wed, 4 Sept 2024 at 17:50, yudhi s wrote= : > >> Hello, >> In postgres database , we have all the tables with audit columns like >> created_by_user, created_timestamp,updated_by_user, updated_timestamp. S= o >> we have these fields that were supposed to be populated by the time at >> which the insert/update operation happened on the database but not at th= e >> application level. So we are planning to populate the created_by_user, >> created_timestamp columns by setting a default value of "current_timesta= mp" >> and "current_user" for the two columns, but no such this is available t= o >> populate while we do the update of the row, so the only option seems to = be >> through a trigger. >> >> So wanted to check with the experts here ,considering the table will be >> DML heavy table (300M+ transactions will be inserted daily), Is is okay = to >> have the trigger for this table for populating all the audit columns or >> should we keep default for created_by_user, created_timestamp and just >> trigger for the update related two audit column? Basically wanted to see= , >> if the default value does the same thing as a trigger or it does somethi= ng >> more optimally than trigger? >> >> Regards >> Yudhi >> > Thank you so much. So do you mean to say that , we should add default values for the create_timestamp and create_user_id as current_timestamp and current_user, but for update_user_id and update_timestamp , we can ask the application to update the values manually , whenever they are executing the update statement on the rows? --00000000000018c1c006214ae5aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Sep 4, 2024 at 6:29=E2=80=AFPM Mu= hammad Usman Khan <usman.k@bitnin= e.net> wrote:
Hi,

In your scenario, triggers can= add some overhead since they require extra processing after each update op= eration. Considering the size of your table and the high transaction volume= , you need to observe that this might significantly affect performance.=C2= =A0 =C2=A0

<= div dir=3D"ltr">


On Wed, 4= Sept 2024 at 17:50, yudhi s <learnerdatabase99@gmail.com> wrote:
=
Hello,In postgres database , we have all the tables with audit columns like cr= eated_by_user, created_timestamp,updated_by_user, updated_timestamp. So we = have these=C2=A0fields that were supposed to be populated by the time at wh= ich the insert/update operation happened on the database but not at the app= lication level. So we are planning=C2=A0to populate the created_by_user, cr= eated_timestamp columns by setting a default value of "current_timesta= mp" and "current_user" for the two columns,=C2=A0 but no suc= h this is available to populate while we do the update of the row, so the o= nly option seems=C2=A0to be through a trigger.=C2=A0

So wanted to check with the experts here=C2=A0 ,considering the table wi= ll be DML heavy table (300M+ transactions will be inserted daily), Is is ok= ay to have the trigger for this table for populating all the audit columns= =C2=A0or should=C2=A0we keep default for=C2=A0 created_by_user, created_tim= estamp and just trigger for the update related two audit column? Basically = wanted to see, if the default value does the same thing as a trigger or it = does something more optimally than trigger?

Regard= s
Yudhi

Thank you so much. So do you mean to say that , we should add default= values for the create_timestamp and create_user_id as current_timestamp an= d current_user,=C2=A0 but for update_user_id and update_timestamp , we can = ask the application to update the values manually , whenever=C2=A0they are = executing the update statement on the rows?=C2=A0
--00000000000018c1c006214ae5aa--