public inbox for [email protected]  

help / color / mirror / Atom feed

From: Purav Chovatia <[email protected]>
To: [email protected]
Subject: Stored Procedure Performance
Date: Tue, 3 Oct 2017 20:03:16 +0530
Message-ID: <CADrzpjHChC6q0NGMG0wZUFvj-A0QO3WL9JONLcmRRCZuPnQQNQ@mail.gmail.com> (raw)
List-Unsubscribe:  <mailto:[email protected]?body=unsub%20pgsql-performance>

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

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected]
  Subject: Re: Stored Procedure Performance
  In-Reply-To: <CADrzpjHChC6q0NGMG0wZUFvj-A0QO3WL9JONLcmRRCZuPnQQNQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox