| From: | tomohiro hiramitsu <hiramit(dot)tm(at)gmail(dot)com> |
|---|---|
| To: | Kasahara Tatsuhito <kasahara(dot)tatsuhito(at)gmail(dot)com> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, skoposov(at)ed(dot)ac(dot)uk, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #16722: PG hanging on COPY when table has close to 2^32 toasts in the table. |
| Date: | 2021-01-21 12:07:32 |
| Message-ID: | CAOR2cEbVUDJJ_sDjONz3Yg_uCJQPN6TNZVhjUVm3WNZ1Quw9Ug@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi
On Wed, Jan 6, 2021 at 11:13 AM Kasahara Tatsuhito <
kasahara(dot)tatsuhito(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sergey Mirvoda | 2021-01-21 14:13:08 | Re: Проблемы с Postgresql 11 |
| Previous Message | Сибиряков Евгений Олегович | 2021-01-21 10:55:08 | Проблемы с Postgresql 11 |