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