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 →
-
Log when GetNewOidWithIndex() fails to find unused OID many times.
- 7fbcee1b2d5f 14.0 landed
-
Add tests for bytea LIKE operator
- eb42110d952f 14.0 cited