Re: BUG #16722: PG hanging on COPY when table has close to 2^32 toasts in the table.

tomohiro hiramitsu <hiramit.tm@gmail.com>

From: tomohiro hiramitsu <hiramit.tm@gmail.com>
To: Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>
Cc: Magnus Hagander <magnus@hagander.net>, Andres Freund <andres@anarazel.de>, Fujii Masao <masao.fujii@oss.nttdata.com>, skoposov@ed.ac.uk, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2021-01-21T12:07:32Z
Lists: pgsql-bugs
Hi

On Wed, Jan 6, 2021 at 11:13 AM Kasahara Tatsuhito <
kasahara.tatsuhito@gmail.com> wrote:

>
> > By the way
> > How about distributing OIDs so that the GetNewOidWithIndex function
> doesn't take long to find an available OID?
> > For example, skip one and assign an OID.
> >
> > As a side effect of this method, the OID progresses faster.
> > (Maybe the btree index will be fragmented faster)
> I think the idea of assigning OIDs to sparse is interesting.
> However, I think it needs to find out how much it will affect the
> performance.
> It could be a non-negligible overhead, especially for large amounts of
> data insertion/updating.
>
I agree with you. I can't predict the impact of this method on performance.
I may need to do some performance tests to find out the impact of this
method.

Thank you for your reply.

regards.
-- 
Tomohiro Hiramitsu
NTT Open Source Software Center

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Log when GetNewOidWithIndex() fails to find unused OID many times.

  2. Add tests for bytea LIKE operator