Re: COPY and heap_sync
| От | Amit Kapila |
|---|---|
| Тема | Re: COPY and heap_sync |
| Дата | |
| Msg-id | CAA4eK1Ke7+872kFsBSHYFYy8E=Lv1d19wAt0gwQjTvabFZQ=TQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | COPY and heap_sync (Jeff Janes <jeff.janes@gmail.com>) |
| Ответы |
Re: COPY and heap_sync
|
| Список | pgsql-hackers |
On Sat, Aug 30, 2014 at 11:56 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
>
> If you insert tuples with COPY into a table created or truncated in the same transaction, at the end of the COPY it calls heap_sync.
>
> But there cases were people use COPY in a loop with a small amount of data in each statement. Now it is calling heap_sync many times, and if NBuffers is large doing that gets very slow.
>
> Could the heap_sync be safely delayed until the end of the transaction, rather than the end of the COPY?
Wouldn't unconditionally delaying sync until end of transaction
>
> If you insert tuples with COPY into a table created or truncated in the same transaction, at the end of the COPY it calls heap_sync.
>
> But there cases were people use COPY in a loop with a small amount of data in each statement. Now it is calling heap_sync many times, and if NBuffers is large doing that gets very slow.
>
> Could the heap_sync be safely delayed until the end of the transaction, rather than the end of the COPY?
Wouldn't unconditionally delaying sync until end of transaction
can lead to burst of I/O at that time especially if there are many
such copy commands in a transaction, leading to delay in some
other operation's that might be happening concurrently in the
system.
В списке pgsql-hackers по дате отправления: