Re: [HACKERS] Parallel COPY FROM execution

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] Parallel COPY FROM execution
Дата
Msg-id CAFj8pRDm3OMxnPmBQGef77_Aj63x-_d8Dp7=UYRzVBDVKV1=Wg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Parallel COPY FROM execution  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: [HACKERS] Parallel COPY FROM execution  (Alex K <kondratov.aleksey@gmail.com>)
Список pgsql-hackers


2017-06-30 15:45 GMT+02:00 Pavel Stehule <pavel.stehule@gmail.com>:


2017-06-30 15:42 GMT+02:00 Alex K <kondratov.aleksey@gmail.com>:
On Fri, Jun 30, 2017 at 3:35 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>
>
> 2017-06-30 14:23 GMT+02:00 Alex K <kondratov.aleksey@gmail.com>:
>>
>> Thus, it results in a ~60% performance boost per each x2 multiplication of
>> parallel processes, which is consistent with the initial estimation.
>>
>
> the important use case is big table with lot of indexes. Did you test
> similar case?

Not yet, I will try it, thank you for a suggestion. But how much is it
'big table' and 'lot of indexes' in numbers approximately?

the size is about 1/3 RAM size, 60 columns, 30 indexes

maybe some variants can be interesting .. 1/30 RAM, 1/20 RAM, 1/10 RAM, 1/3 RAM 

and a) when bottleneck is IO, b) when bottleneck is CPU

Pavel
 

Regards

Pavel
 

Also, index updates and constraint checks performance are what I cannot
control during COPY execution, so probably I have not to care too much
about that. But of course, it is interesting, how does COPY perform in
that case.


Alexey


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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] Parallel COPY FROM execution
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] "SELECT *" vs hidden columns and logical column order