On Thu, Sep 1, 2016 at 9:43 AM, Peter Geoghegan <p...@heroku.com> wrote: > On Wed, Aug 31, 2016 at 8:26 PM, Amit Kapila <amit.kapil...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers