Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dzOGB-0004vH-2H for pgsql-performance@arkaria.postgresql.org; Tue, 03 Oct 2017 14:33:23 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dzOGA-00028n-LW for pgsql-performance@arkaria.postgresql.org; Tue, 03 Oct 2017 14:33:22 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dzOG9-00024c-5o for pgsql-performance@postgresql.org; Tue, 03 Oct 2017 14:33:21 +0000 Received: from mail-wr0-x229.google.com ([2a00:1450:400c:c0c::229]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1dzOG6-0008Ds-5J for pgsql-performance@postgresql.org; Tue, 03 Oct 2017 14:33:20 +0000 Received: by mail-wr0-x229.google.com with SMTP id o44so4675510wrf.11 for ; Tue, 03 Oct 2017 07:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Szqd6UwwKQ4o1RM98sS57V+P50cIwhB8yvXXqy4AkKw=; b=k3EQrVhD2tYhd1u3mTe2qJnby7XjWr8SNnBtTIxeofW0XsbPQ1YlAPSJT9ssYl9OHC HiMdaNclcJnOltX6nk+PJnf6PqTgR6jO3AUD8A7bq+RmgiX1lqPkV+9P1LhW3P+zQDsy t6Bcf/MZ7wpb6Fg21F+tj6a81F+TV1Lgm7Cjp5nVWcAwlJoe2YR/q56uT7eSIO8mRH0n Kpiq4quy7mB4G7w05FNKMJ4wPIdg52Gz/PoyWODl9uvv7kPCH24fQrXZSwguQCLK69rj QqT2nPBKPSUtTYRCpRVjwXLYt7pxlJe5wUgHPljdxuZXA+yEru1CzaYmnZlny4SvXUxJ 309A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Szqd6UwwKQ4o1RM98sS57V+P50cIwhB8yvXXqy4AkKw=; b=n3wFF4+QrDN2Ik003vjx5q+oIu+4V7WePAxxV3y41lyv0LyGxkESmymh4okqkRrFoJ M7jhbe3wktULKYQnPeRxbiuy1Eg01bGK6nZienH/gkSWqVFEkO4vLqmMbk/I/6CSmDUn JUWB4biC5c60zYFli9KCNnhgVtMqjomfwtfR7s0EaI1ja2CgzaJ07ISpnlGS2Rrgv9xq +bSMc446CLBZuOc1OPbrewoEAd1QJgJvdn6qBpYyYsW+ah9Zw7WYst6A7EEy8Vnwye/U g0VdctDyr2CqoPjTwe0W4jat4yOrWnQfhiI04Za0h5Iy63f20cpDIwla+JSKkwL423L4 vnZQ== X-Gm-Message-State: AMCzsaUxWGhovh+ts56/IZcbTpy5nlnDKfFum817GL9zzV7l7DfdaWyu QIjIYEgpvsMmYPI4VR+SrFBbzJDCvfBZrS3lIrY= X-Google-Smtp-Source: AOwi7QBClqtmffSc1XErcPz6FF+6C3RmWuA7o6GusqvTHlCFL51T//LQcgipRAsY7IFXahIU0iikBDubDKi9DbZiMuw= X-Received: by 10.223.166.119 with SMTP id k110mr6176171wrc.182.1507041196844; Tue, 03 Oct 2017 07:33:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.29 with HTTP; Tue, 3 Oct 2017 07:33:16 -0700 (PDT) From: Purav Chovatia Date: Tue, 3 Oct 2017 20:03:16 +0530 Message-ID: Subject: Stored Procedure Performance To: pgsql-performance@postgresql.org Content-Type: multipart/alternative; boundary="f403045cf0fe332c7b055aa55fb0" List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org --f403045cf0fe332c7b055aa55fb0 Content-Type: text/plain; charset="UTF-8" Hello, I come from Oracle world and we are porting all our applications to postgresql. The application calls 2 stored procs, - first one does a few selects and then an insert - second one does an update The main table on which the insert and the update happens is truncated before every performance test. We are doing about 100 executions of both of these stored proc per second. In Oracle each exec takes about 1millisec whereas in postgres its taking 10millisec and that eventually leads to a queue build up in our application. All indices are in place. The select, insert & update are all single row operations and use the PK. It does not look like any query taking longer but something else. How can I check where is the time being spent? There are no IO waits, so its all on the CPU. btw, postgres and oracle both are installed on the same server, so no differences in env. All suggestions welcome but I am more of looking at tools or any profilers that I can use to find out where is the time being spent because we believe most of our applications will run into similar issues. The version is 9.6 on RHEL 7.2. Many thanks in advance. Regards, Purav --f403045cf0fe332c7b055aa55fb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I come from Oracle world and we = are porting all our applications to postgresql.

Th= e application calls 2 stored procs,=C2=A0
- first one does a few = selects and then an insert
- second one does an update
=
The main table on which the insert and the update happens is= truncated before every performance test.

We are d= oing about 100 executions of both of these stored proc per second.

In Oracle each exec takes about 1millisec whereas in postg= res its taking 10millisec and that eventually leads to a queue build up in = our application.

All indices are in place. The sel= ect, insert & update are all single row operations and use the PK.

It does not look like any query taking longer but some= thing else. How can I check where is the time being spent? There are no IO = waits, so its all on the CPU.

btw, postgres and or= acle both are installed on the same server, so no differences in env.
=

All suggestions welcome but I am more of looking at too= ls or any profilers that I can use to find out where is the time being spen= t because we believe most of our applications will run into similar issues.=

The version is 9.6 on RHEL 7.2.

Many thanks in advance.

Regards,
Purav
--f403045cf0fe332c7b055aa55fb0--