One of our Oracle apps had a performance problem - it was running several HOURS over its normal runtime.
It's a procedure that handles row visibility changes when the definitions for the visibility change.
The procedure basically deletes the entire relation of the visibility to the rows and then rebuilds it. As a single transaction, its not a great way, but there could be worse.
The problem is somebody decided the rebuild should be an explicit loop and it should reinsert, row-by-row, and commit after every row. Effectively now the user has their whole visibility wiped out and very slowly added back in.
Why they put the explicit commits at the bottom of the loop? God only knows. However, I'm really sure that the whole loss of temporary visibility was an unintentional consequence.
Luckily, in Postgres, is simply a non-issue. A transaction cannot be committed halfway through. Why? Because its a transaction! It's a feature that I've seen people ask to be put in Postgres a few times and frankly, I hope it never happens. Its a "feature" that is too often abused from my perspective.
Of features in Postgres, it looks like MERGE may finally make it into Postgres next version. Nothing is for sure, but its got a chance!
It's a procedure that handles row visibility changes when the definitions for the visibility change.
The procedure basically deletes the entire relation of the visibility to the rows and then rebuilds it. As a single transaction, its not a great way, but there could be worse.
The problem is somebody decided the rebuild should be an explicit loop and it should reinsert, row-by-row, and commit after every row. Effectively now the user has their whole visibility wiped out and very slowly added back in.
Why they put the explicit commits at the bottom of the loop? God only knows. However, I'm really sure that the whole loss of temporary visibility was an unintentional consequence.
Luckily, in Postgres, is simply a non-issue. A transaction cannot be committed halfway through. Why? Because its a transaction! It's a feature that I've seen people ask to be put in Postgres a few times and frankly, I hope it never happens. Its a "feature" that is too often abused from my perspective.
Of features in Postgres, it looks like MERGE may finally make it into Postgres next version. Nothing is for sure, but its got a chance!