On 24 July 2018 at 06:38, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> On 20.07.18 16:57, David Rowley wrote:
>> One final note: I'm not entirely convinced we need this adaptive
>> code, but it seems easy enough to rip it back out if it's more trouble
>> than it's worth. But if the other option is a GUC, then I'd rather
>> stick with the adaptive code, it's likely going to do much better than
>> a GUC since it can change itself during the copy which will be useful
>> when the stream contains a mix small and large sets of consecutive
>> tuples which belong to the same partition.
>
> I think some kind of way to switch between the two code paths would be
> desirable. For example, with hash partitioning, it's likely that in
> many cases you won't find any adjacent candidates in batches of
> significant size. So then you've just made everything 5% slower.
> Unless we can make the multi-insert path itself faster.
>
> The particular heuristic you have chosen seems sensible to me, but we'll
> have to see how it holds up in practice.
Thanks for having a look at this. You're probably right here,
although, the slowdown I measured was 2.2%, not 5%. I had it in my
head that it was about 1%, but for 2.2% it seems worth the extra code.
I've attached a small delta against the v2 patch that fixes up a few
comments and gets rid of a needless assignment.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
