Re: Making "COPY partitioned_table FROM" faster

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, khuddleston(at)pivotal(dot)io
Subject: Re: Making "COPY partitioned_table FROM" faster
Date: 2018-07-27 02:26:55
Message-ID: CAKJS1f9Fwfb4ZrySQa31JXzdr_1PpxPxdFsYArCgy_MjHx9BaQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 27 July 2018 at 05:30, Melanie Plageman <melanieplageman(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-07-27 02:31:23 Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack
Previous Message Thomas Munro 2018-07-27 02:04:05 Re: pread() and pwrite()