Re: WIP patch for hint bit i/o mitigation

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Merlin Moncure'" <mmoncure(at)gmail(dot)com>, "'Hari Babu'" <haribabu(dot)kommi(at)huawei(dot)com>
Cc: "'Greg Smith'" <greg(at)2ndquadrant(dot)com>, "'Atri Sharma'" <atri(dot)jiit(at)gmail(dot)com>, "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP patch for hint bit i/o mitigation
Date: 2012-12-14 13:57:53
Message-ID: 003101cdda03$04437820$0cca6860$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thursday, December 13, 2012 8:02 PM Merlin Moncure wrote:
> On Thu, Dec 13, 2012 at 7:06 AM, Hari Babu <haribabu(dot)kommi(at)huawei(dot)com>
> wrote:
> > Please find the review of the patch.
>
>
> Thanks for detailed review!
>
> > Basic stuff:
> > ------------
> > - Patch applies with offsets.
> > - Compiles cleanly with no warnings
> > - Regression Test pass.
> >
> > Code Review:
> > -------------
> > 1. Better to set the hint bits for the tuples in a page, if
> the page
> > is already dirty.
>
> This is true today but likely less true if/when page checksums come
> out. Also it complicates the code a little bit.
>
> > Default tables select : 64980.736149 64550.118693
> > Unlogged tables select: 64874.974334 64550.118693
>
> So it looks like the extra tests visibility routines are causing 0.7%
> performance hit.
>
> > Multiple transaction bulk inserts: Select performance (refer script -1
> & 2
> > which attached)
> > sequential scan: 6.492680 6.382014
> > Index scan: 1.386851 1.36234
> >
> > Single transaction bulk inserts: Select performance (refer script - 3
> & 4
> > which attached)
> > sequential scan: 6.49319 6.3800147
> > Index scan: 1.384121 1.3615277
>
> The performance hit is higher here. Almost 2%. This is troubling.
>
> > Long transaction open then Vacuum & select performance in milli
> seconds.
> > (refer reports output)
> > Testcase - 3:
> > Single Vacuum Perf : 128.302 ms 181.292 ms
> > Single select perf : 214.107 ms 177.057 ms
> > Total : 342.409 ms 358.349 ms
> >
> > I was not able to find the reason why in some of cases results are low
> so
> > please use the attached scripts to validate the same.
>
> I need to validate the vacuum results. It's possible that this is
> solvable by tweaking xmin check inside vacuum. Assuming that's fixed,
> the question stands: do the results justify the change? I'd argue
> 'maybe'

We can try with change (assuming change is small) and see if the performance
gain is good, then discuss whether it really justifies.
I think the main reason for Vacuum performance hit is that in the test pages
are getting dirty only due to setting of hint bit
by Vacuum.

>-- I'd like to see the bulk insert performance hit reduced if
> possible.

I think if we can improve performance for bulk-insert case, then this patch
has much more value.

With Regards,
Amit Kapila.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Albe Laurenz 2012-12-14 14:31:07 Re: [v9.3] writable foreign tables
Previous Message Amit Kapila 2012-12-14 13:42:57 Re: Performance Improvement by reducing WAL for Update Operation