Re: IO related waits
| От | Ron Johnson |
|---|---|
| Тема | Re: IO related waits |
| Дата | |
| Msg-id | CANzqJaB28bd_DmMdztFbY8fqhgOXf8i5zLRz-8C7SvCfbuJA0Q@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: IO related waits (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-general |
On Fri, Sep 20, 2024 at 4:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
veem v <veema0000@gmail.com> writes:
> Able to reproduce this deadlock graph as below. Now my question is , this
> is a legitimate scenario in which the same ID can get inserted from
> multiple sessions and in such cases it's expected to skip that (thus "On
> conflict Do nothing" is used) row. But as we see it's breaking the code
> with deadlock error during race conditions where a lot of parallel threads
> are operating. So how should we handle this scenario?
Do you have to batch multiple insertions into a single transaction?
If so, can you arrange to order them consistently across transactions
(eg, sort by primary key before inserting)?
That's exactly what I did back in the day. Because of database buffering, sorting the data file at the OS level made the job 3x as fast as when the input data was random.
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> crustacean!
В списке pgsql-general по дате отправления: