From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: 2023-08-10 release announcement draft |
Date: | 2023-08-08 01:53:30 |
Message-ID: | CAApHDvqUxxu_x5z0LoiumpzwedMrjzp7gV9KMgVzwy+KJg1DOA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 8 Aug 2023 at 13:49, Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
>
> On 8/7/23 9:45 PM, David Rowley wrote:
>
> >> * Fix a performance regression when running concurrent
> >> [`COPY`](https://www.postgresql.org/docs/16/sql-copy.html) statements on a
> >> single table.
> >
> > I think this is still outstanding. A bit of work has been done for the
> > int parsing regression but it seems there's still a performance
> > regression when running multiple COPYs on the same table, per [1].
>
> Hm, the open item was closed[1] -- was that premature, or is this a new
> issue (have not yet read the thread you referenced)?
I closed it thinking that enough had been done to resolve the
performance regression. In the linked thread, Sawadasan shows that
that's not the case. So, yes, premature. I've reverted the change to
the open items list now.
David
From | Date | Subject | |
---|---|---|---|
Next Message | 熊艳辉 | 2023-08-08 01:54:38 | how to ensure parallel restore consistency ? |
Previous Message | Jonathan S. Katz | 2023-08-08 01:49:26 | Re: 2023-08-10 release announcement draft |