Re: non-bulk inserts and tuple routing

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: non-bulk inserts and tuple routing
Дата
Msg-id CAFjFpReNQO55rdO2Fa62azym8LYkijYRk0DSuUyxSB3ibwnNhA@mail.gmail.com
обсуждение исходный текст
Ответ на non-bulk inserts and tuple routing  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: non-bulk inserts and tuple routing  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On Tue, Dec 19, 2017 at 3:36 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
>
> * Bulk-inserting 100,000 rows using COPY:
>
> copy t1 from '/tmp/t1.csv' csv;
>
> * Times in milliseconds:
>
> #parts           HEAD        Patched
>
>      8        458.301        450.875
>     16        409.271        510.723
>     32        500.960        612.003
>     64        430.687        795.046
>    128        449.314        565.786
>    256        493.171        490.187

While the earlier numbers were monotonically increasing with number of
partitions, these numbers don't. For example the number on HEAD with 8
partitions is higher than that with 128 partitions as well. That's
kind of wierd. May be something wrong with the measurement. Do we see
similar unstability when bulk inserting in an unpartitioned table?
Also, the numbers against 64 partitions are really bad. That's almost
2x slower.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: non-bulk inserts and tuple routing
Следующее
От: Feike Steenbergen
Дата:
Сообщение: Add hint about replication slots when nearing wraparound