Re: Catching errors inside a LOOP is causing performance issues

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Denisa Cirstescu <Denisa(dot)Cirstescu(at)tangoe(dot)com>
Cc: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Catching errors inside a LOOP is causing performance issues
Date: 2017-09-27 16:59:40
Message-ID: CAKFQuwZ_88me2heiJ6=5S1oyNDK0OcVvJO=xM1y20Oy9WKhJtA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Sep 25, 2017 at 9:13 AM, Denisa Cirstescu <
Denisa(dot)Cirstescu(at)tangoe(dot)com> wrote:

>
> Can someone please explain to me why this worked?
>
> What happened behind the scenes?
>
> I suspect that when you catch exceptions inside of a LOOP and the code
> ends up generating an exception, Postgres can’t use cached plans to
> optimize that code so it ends up planning the code at each iteration and
> this causes performance issues.
>
> Is my assumption correct?
>
>
>
​Not sure how much detail you are looking for but the docs say this:

"​Tip: A block containing an EXCEPTION clause is significantly more
expensive to enter and exit than a block without one. Therefore, don't use
EXCEPTION without need."

https://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING

I'm somewhat doubting "plan caching" has anything to do with this; I
suspect its basically that there is high memory and runtime overhead to
deal with the possibilities of needing to convert a exception into a branch
instead of allowing it to be fatal.

David J.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Igor Polishchuk 2017-09-27 17:56:27 Rsync to a recovering streaming replica?
Previous Message George Neuner 2017-09-27 10:06:07 Re: Speed of conversion from int to bigint