Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1muRfD-0005NY-0L for pgsql-admin@arkaria.postgresql.org; Tue, 07 Dec 2021 04:01:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1muRfA-0005LH-Sl for pgsql-admin@arkaria.postgresql.org; Tue, 07 Dec 2021 04:01:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1muRfA-0005L8-GD for pgsql-admin@lists.postgresql.org; Tue, 07 Dec 2021 04:01:08 +0000 Received: from mail-qv1-xf29.google.com ([2607:f8b0:4864:20::f29]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1muRf7-0001tH-Gb for pgsql-admin@lists.postgresql.org; Tue, 07 Dec 2021 04:01:07 +0000 Received: by mail-qv1-xf29.google.com with SMTP id jo22so11909851qvb.13 for ; Mon, 06 Dec 2021 20:01:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=Z6juoDNjvRLt8PB2ru4V82stsxz5vKPGstwpUJ8WJFg=; b=j5yeYWWkV1uhJvOKTUx0X5iV1NYc63L/8m1iCK4vX1AFE9uOoo5j97jmJocCyKR+jo OQm/RtjLqQnBCZKIaGb0Ijdsfk2b9CaP+6xPYXcU2upYpkAgHcFMLOGY3PbI56V27oIV QePa8BfnMXpoZFaverBEf4CC+zv5brxfOYThicYn09b0No0Fi2I7kcBslCuR+aLQAZsP JmyZZgscVV95M633sQfS/WqQ1IG9I+qPtD/ZcTmgL1EZhN7zsY0HLbas/rb0UPQMmUVW XXyn51EHIIVm2TNrmL4RQ6Uj/Ze6xwgza8A4RJgbk/5HIz4IZaPOReM1LtMvqc3MHzwj SAjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=Z6juoDNjvRLt8PB2ru4V82stsxz5vKPGstwpUJ8WJFg=; b=kR4wDDg4Gm1lcRryIYx9zS+Ds5WZbEAwhDrhks/0kNsY7u8TaFOzR8zB1GYDO3IOj5 nbXPoLwwuWN6f9c5Sf1rHyUhQ7a8UvH181LGMKJeWBsC7P3zinrZXQU8L+u1d/r/s1H1 DkPi7YmUYZ0b3Thf5RllMYmmXX2R4yiIWCs7MJOcRT8mOAnPg19szitSljxtTq4q44/w rAJDpUFsziqcQB2+3yBou6WvykT4BYeeJgU9WKUjzcaHttSUfLjJILLFnBtgOb6nTfev KStXh8VFsJlaY1UjHn2cA0WMyEOrwb/OHPDOWYv9fPqFmqZmJMUM9aAU8gz/wbZ+Vbpj C4Ww== X-Gm-Message-State: AOAM530ok0fVCop+qyGlT8TQnUttX9zM7YJ7cMVtwW9ZbXrD+MZ2M27J ShbojH+JyrX/bGQbztUwUzhKeAda+bg2Eg== X-Google-Smtp-Source: ABdhPJz3rUafVRBcqR8a5IbVETG5XorSOsKlzlhf2AfS+icMsY8OVN80zydrFgkYyrjzUm4Q4YiePA== X-Received: by 2002:a05:6214:622:: with SMTP id a2mr44407435qvx.109.1638849662202; Mon, 06 Dec 2021 20:01:02 -0800 (PST) Received: from [192.168.2.100] (pool-72-79-19-93.nwrknj.east.verizon.net. [72.79.19.93]) by smtp.gmail.com with ESMTPSA id a16sm8787830qta.94.2021.12.06.20.01.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Dec 2021 20:01:01 -0800 (PST) Message-ID: <06613990-9967-9304-ddba-e1fed931af80@gmail.com> Date: Mon, 6 Dec 2021 23:01:00 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: Transaction Size in PostgreSQL Content-Language: en-US To: pgsql-admin@lists.postgresql.org References: From: Mladen Gogala In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 12/6/21 22:26, Sivasamy Subramaniam wrote: > Hello Experts, > > I need a query or a way to find the transaction size in postgreSQL. > Can any one provide SQL or a method to figure this out? How do you define transaction size? By the number of bytes it changed? By the duration of the transaction? By the amount of generated WAL entries? Maybe it's the amount of memory consumed by the transaction? All of these quantities could, with a reasonable justification, be called "transaction size". Anyway, the old adage says that size doesn't matter.  It's not the size of transaction that matters, regardless of how the size is defined, it's the magic in the optimizer. I am quoting from memory, I apologize if I got my quotes wrong. Why would you need such a measure? Are you trying to do some capacity planning for moving to the cloud? I have usually used things like "transactions per second" and measured the system response time. You may want to try pg_stat_xact_user_tables which contains the numbers of updated, inserted and fetched rows. That could also be the measure of the transaction size. Probably the most useful way would be to build a measure into the application and let the application measure whatever you define as "transaction size". Regards -- Mladen Gogala Database Consultant Tel: (347) 321-1217 https://dbwhisperer.wordpress.com