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 1slpbO-001RoA-S9 for pgsql-general@arkaria.postgresql.org; Wed, 04 Sep 2024 12:59:15 +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 1slpbN-009RQa-Dd for pgsql-general@arkaria.postgresql.org; Wed, 04 Sep 2024 12:59:13 +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 1slpbM-009RQR-Ud for pgsql-general@lists.postgresql.org; Wed, 04 Sep 2024 12:59:13 +0000 Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1slpbK-0007aH-Hf for pgsql-general@lists.postgresql.org; Wed, 04 Sep 2024 12:59:12 +0000 Received: by mail-pj1-x1030.google.com with SMTP id 98e67ed59e1d1-2d889ba25f7so3221811a91.0 for ; Wed, 04 Sep 2024 05:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitnine-net.20230601.gappssmtp.com; s=20230601; t=1725454748; x=1726059548; 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=HwDlBzmQLQVQ57dlPwUGTazQB1St3G6W0NDNiZxBL30=; b=bUEcEBXMJT6cyEnDeqTX8mRyJRY0YG3Ebgg4KwdV2RQ7hGoBKcHSV0gUVQPF4mhils qM2s8Dvn75o02s2R29cF+aXmp98DYr7ZzcZ8NCfxK2wPhidVoLxwNsfMJb/bTwB+/vZc 4cAUXRIiEqntvS3R7ywn7k9KJErsDRqYuJP93ix0pHsPyZ8SDfIt3fqxnEIjvhyDJezj iU1YQcSnrXuHVqcCoNqX6JQy+KiImlRDO0qa+XYu4mrc2QPjvNGd95O7DIDcr3pLrt8x kSA/NnYAg+xytQvtch6qXHAMjYjkKVgvRKW0sJEUPCaqFzwxCJMJCXLzrsP1eheFMcsZ eELA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725454748; x=1726059548; 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=HwDlBzmQLQVQ57dlPwUGTazQB1St3G6W0NDNiZxBL30=; b=G15rBz9fTbuPAPBW8vnnFAZEzTxLLZMSNn2vTQv8rYbqp8keyQUpCR55efQevcUOpk zbnEtTwDyQ2yuOF9qW8wbkp/SS69aMpQtADx+GVefHoJGIwq/v/czv6bo51mfh2d5bu3 me9m/dro6D1Vbc1IUipW/ZTbdEp9mUYcLg4lQN+qc6DW3vQ4hfVe5SDk8bOxpVaOsE2B ISa+x6/++ilubMpLSEylbaJV/2+t444J8gmNjdVOWZ2FyT67l4Ubmh+c/FrFd0F2b34E S3ERy6jbNdVF1judxsFzxvA6wDQvre6422ulkL6H4J4zknOaATkb0PGmSD1yLSAETr7b PGEQ== X-Gm-Message-State: AOJu0Ywid7qJdre4M7AvPz/pjf7OYx5nY6vSnw1z2VQqHYWme+hOpqpo W0ZVhzTRAqVndrz3JbcNfaYzuNYi/a3fEEb84BysepXnoSrrqGcDAiESfJi8YdtzoNrbPR4lRDr 3cpt0MQRS5/wjyijo0xksICL4rcFRW/Yf9tg+cQ== X-Google-Smtp-Source: AGHT+IGPBj6W4E0mrXVoPPJjUbMpDsNrJV5iTX8F1a9qLUqlvv5BkCaIWFtHJwyNaBriZ5gmG9uJ04aiT8fs1qO/3aM= X-Received: by 2002:a17:90b:358c:b0:2d8:79bf:3873 with SMTP id 98e67ed59e1d1-2d8973a5a01mr11755411a91.29.1725454747769; Wed, 04 Sep 2024 05:59:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Muhammad Usman Khan Date: Wed, 4 Sep 2024 17:58:56 +0500 Message-ID: Subject: Re: question on audit columns To: yudhi s Cc: pgsql-general Content-Type: multipart/alternative; boundary="000000000000513b6f06214abdb7" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000513b6f06214abdb7 Content-Type: text/plain; charset="UTF-8" Hi, In your scenario, triggers can add some overhead since they require extra processing after each update operation. Considering the size of your table 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. So > 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 the > application level. So we are planning to populate the created_by_user, > created_timestamp columns by setting a default value of "current_timestamp" > and "current_user" for the two columns, but no such this is available to > 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 something > more optimally than trigger? > > Regards > Yudhi > --000000000000513b6f06214abdb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

In your scenario, triggers can add = some overhead since they require extra processing after each update operati= on. 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>


On Wed, 4 Sept 2024 at 17:50, yudhi s <learnerdatabase99@gmail.com> wrot= e:
Hello,
In postgres database , we have all the tables with audit col= umns like created_by_user, created_timestamp,updated_by_user, updated_times= tamp. So we have these=C2=A0fields that were supposed to be populated by th= e time at which the insert/update operation happened on the database but no= t at the application level. So we are planning=C2=A0to populate the created= _by_user, created_timestamp columns by setting a default value of "cur= rent_timestamp" and "current_user" for the two columns,=C2= =A0 but no such this is available to populate while we do the update of the= row, so the only option seems=C2=A0to be through a trigger.=C2=A0

So wanted to check with the experts here=C2=A0 ,considerin= g the table will be DML heavy table (300M+ transactions will be inserted da= ily), Is is okay 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_timestamp and just trigger for the update related two audit colum= n? Basically wanted to see, if the default value does the same thing as a t= rigger or it does something more optimally than trigger?

Regards
Yudhi
--000000000000513b6f06214abdb7--