Re: Making "COPY partitioned_table FROM" faster

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Making "COPY partitioned_table FROM" faster
Дата
Msg-id CAKJS1f9Fwfb4ZrySQa31JXzdr_1PpxPxdFsYArCgy_MjHx9BaQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Making "COPY partitioned_table FROM" faster  (Melanie Plageman <melanieplageman@gmail.com>)
Ответы Re: Making "COPY partitioned_table FROM" faster  (Melanie Plageman <melanieplageman@gmail.com>)
Список pgsql-hackers
On 27 July 2018 at 05:30, Melanie Plageman <melanieplageman@gmail.com> wrote:
> On patched code line 2564, there is a missing parenthesis. It might be
> better to remove the parentheses entirely and, while you're at it, there is
> a missing comma.

Thanks for noticing that.

Fixed in the attached v4. That's the only change.

> Regarding the performance improvement and code diff from v2 to v3:
> The rearranging of the code in v3 makes sense and improves the flow of the
> code, however, I stared at it for awhile and couldn't quite work out in my
> head which part caused the significant improvement from v2.
> I would have thought that a speedup from patch v2 to v3 would have come from
> doing multi-inserts less often when the target partition is switching a lot,
> however, looking at the v2 to v3 diff, I can't see how any of the changes
> would have caused a decrease in the number of multi-inserts given the same
> data and target table ddl.
> So, I thinking I'm missing something. Which of the changes would cause the
> performance improvement from patch v2 to v3? My understanding is:

My guess is that the compile rearranged the code move some of the
unlikely code out of line, perhaps to the end of the function making
the common working set of code fit the instruction cache, where maybe
before there was some cache missed. I've no evidence of that as I
didn't look at the assembly code or do any profiling.

You could probably narrow it down by reverting those changed
one-by-one and seeing if it was just one in particular that caused the
performance improvement or if it was some combination of the changed.
Sounds like that would take quite a bit of time and it would only be
for a learning experience, but an interesting one!

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: pread() and pwrite()
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: BUG #15182: Canceling authentication due to timeout aka Denialof Service Attack