On Thu, Mar 31, 2016 at 4:28 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Mar 31, 2016 at 12:59 AM, Dilip Kumar <dilipbal...@gmail.com>
> > On Tue, Mar 29, 2016 at 10:08 AM, Amit Kapila <amit.kapil...@gmail.com>
> > wrote:
> >> Yes, that makes sense. One more point is that if the reason for v13
> >> giving better performance is extra blocks (which we believe in certain
> >> can leak till the time Vacuum updates the FSM tree), do you think it
> >> sense to once test by increasing lockWaiters * 20 limit to may be
> >> lockWaiters * 25 or lockWaiters * 30.
> > I tested COPY 10000 record, by increasing the number of blocks just to
> > out why we are not as good as V13
> > with extraBlocks = Min( lockWaiters * 40, 2048) and got below results..
> > COPY 10000
> > --------------------
> > Client Patch(extraBlocks = Min( lockWaiters * 40, 2048))
> > -------- ---------
> > 16 752
> > 32 708
> > This proves that main reason of v13 being better is its adding extra
> > without control.
> > though v13 is better than these results, I think we can get that also by
> > changing multiplier and max limit .
> > But I think we are ok with the max size as 4MB (512 blocks) right?
> Yeah, kind of. But obviously if we could make the limit smaller
> without hurting performance, that would be better.
> Per my note yesterday about performance degradation with parallel
> COPY, I wasn't able to demonstrate that this patch gives a consistent
> performance benefit on hydra - the best result I got was speeding up a
> 9.5 minute load to 8 minutes where linear scalability would have been
> 2 minutes.
Is this test for unlogged tables? As far as I understand this patch will
show benefit if Data and WAL are on separate disks or if you test them with
unlogged tables, otherwise the WAL contention supersedes the benefit of