On Thu, Sep 1, 2016 at 9:43 AM, Peter Geoghegan <pg@heroku.com> wrote:
> On Wed, Aug 31, 2016 at 8:26 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>> As far as I am understanding things, we are aiming at something that
>>> could be used on production systems.
>>>
>>
>> I don't think you can enable it by default in production systems.
>> Enabling it will lead to significant performance drop as it writes the
>> whole page after each record for most type of RMGR ID's.
>>
>>> And, honestly, any people
>>> enabling it would just do it for all RMGRs because that's a
>>> no-brainer.
>>
>> Agreed, but remember enabling it for all is not free.
>
> I have sympathy for the idea that this should be as low overhead as
> possible, even if that means adding complexity to the interface --
> within reason. I would like to hear a practical example of where this
> RMGR id interface could be put to good use, when starting with little
> initial information about a problem.
>
One example that comes to mind is for the cases where the problem
reproduces only under high concurrency or some stress test. Now assume
the problem is with index, enabling it for all rmgr's could reduce the
probability of problem due to it's performance impact. The second
advantage which I have already listed is it helps in future
development like the one I am doing now for hash indexes (making them
logged).
> And, ideally, we'd also have some
> indication of how big a difference that would make, it terms of
> measurable performance impact.
>
Yes, that's a valid point. I think we can do some tests to see the difference.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com