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."
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.
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 |