Re: BUG #19103: Canceled INSERT statement can still influence the performance of subsequent SELECT statement

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: "jinhui(dot)lai(at)qq(dot)com" <jinhui(dot)lai(at)qq(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #19103: Canceled INSERT statement can still influence the performance of subsequent SELECT statement
Date: 2025-11-04 13:26:01
Message-ID: CAKFQuwYNv6cGvMaXUp_Sh=Svc2KhekE39-FkCxNKXdZzHoYmYA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tuesday, November 4, 2025, PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:

> The following bug has been logged on the website:
>
> Bug reference: 19103
> Logged by: Jinhui Lai
> Email address: jinhui(dot)lai(at)qq(dot)com
> PostgreSQL version: 18.0
> Operating system: ubuntu 22.04
> Description:
>
> Dear PG developers:
>
> Thanks for reading my report. Here, I find a performance issue. I have
> found a performance issue where a canceled INSERT statement appears to
> negatively impact the performance of subsequent SELECT queries.

This doesn’t feel like a bug. Processing deleted rows is expensive and
some of that work happens during selects if/when those dead rows are
encountered.

> This performance degradation could affect systems where large batch
> operations are frequently started and canceled, potentially impacting
> overall database responsiveness.
>

Temporary tables are nice for this kind of flow. Don’t touch production
tables until you know what you are going to insert is going to stick.

David J.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrei Lepikhov 2025-11-04 13:43:05 Re: BUG #19102: Assertion failure in generate_orderedappend_paths with aggregate pushdown
Previous Message PG Bug reporting form 2025-11-04 12:08:00 BUG #19103: Canceled INSERT statement can still influence the performance of subsequent SELECT statement