BUG #16967: Extremely slow update statement in trigger

From: PG Bug reporting form <noreply(at)postgresql(dot)org>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Cc: postgres(at)burri(dot)li
Subject: BUG #16967: Extremely slow update statement in trigger
Date: 2021-04-16 16:52:15
Message-ID: 16967-39db5f50df41173a@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 16967
Logged by: Nicolas Burri
Email address: postgres(at)burri(dot)li
PostgreSQL version: 13.2
Operating system: Linux &amp; Windows
Description:

Hi,
During a data migration our production system spent several hours in a
simple update statement of a table with very few columns and about 200k
records. We managed to reproduce the problem and a minimal setup for
reproduction can be found here:
https://www.dropbox.com/s/mxjavpl43s48hdg/bug_report.sql. The bug seems to
be related to query plan caching and can be reproduced on postrgres 11.11
and 13.2 (I have not run tests with other versions)

Description:
We use a statement level trigger to log changes to records in a certain
table. On every update, the trigger calls a function comparing “old table”
and “new table”. For every record changed by the statement, the function
inserts a new record in a “log” table. In the following scenario, execution
times explode:
First, execute an update statement that affects no rows. This query is fast
and completes within milliseconds. Then, execute a second update statement
that affects a lot of records. At 200k records, this query runs for more
than 4h on my workstation. If we call “discard plans” before executing the
second update statement, or if we do not execute the first statement at all,
the update of all rows completes within about 1 second.

Thanks and best Regards
Nicolas

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2021-04-16 19:18:45 BUG #16968: Planner does not recognize optimization
Previous Message Tom Lane 2021-04-16 16:49:50 Re: BUG #16966: Nested loop joining across tables with varchar -> bpchar cast always scans varchar table first