Re: WIP patch for hint bit i/o mitigation

From: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>
To: Craig Ringer <craig(at)2ndQuadrant(dot)com>
Cc: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Hari Babu <haribabu(dot)kommi(at)huawei(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP patch for hint bit i/o mitigation
Date: 2013-01-18 14:57:04
Message-ID: 0CE06BEF-DDB8-4DE4-A666-5E40240E7894@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 18-Jan-2013, at 17:04, Craig Ringer <craig(at)2ndQuadrant(dot)com> wrote:

> On 12/14/2012 09:57 PM, Amit Kapila wrote:
>>>
>>> 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.
> Has there been any movement in this - more benchmarks and data showing
> that it really does improve performance, or that it really isn't helpful?
>
> --
> Craig Ringer http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Training & Services

Hello all,

Sorry for the delay in updating the hackers list with the current status.

I recently did some profiling using perf on PostgreSQL 9.2 with and without our patch.

I noticed that maximum time is being spent on heapgettup function. Further investigation and a bit of a hunch leads me to believe that we may be adversely affecting the visibility map optimisation that directly interact with the visibility functions, that our patch straight away affects.

If this is the case, we may really need to get down to the design of our patch, and maybe see which visibility function/functions we are affecting, and see if we can mitigate the affect.

Please let me know your inputs on this.

Regards,

Atri

>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-01-18 14:58:53 Re: Event Triggers: adding information
Previous Message Stephen Frost 2013-01-18 14:48:58 Re: proposal: fix corner use case of variadic fuctions usage