> > And I fixed them as quickly as humanly possible. >
Yes, you have responded to them quickly, but I didn't get a chance to re-verify all of those. However, I think the main point Robert wants to say is that somebody needs to dig the complete patch to see if there is any kind of problems with it.
There are no two views about that. I don't even claim that more problems won't be found during in-depth review. I was only responding to his view that I did not do much to address the regressions reported during the review/tests.
> 5. Added code to set a CLEAR pointer to a WARM pointer when we know that the > entire chain is WARM. This should address the workload Dilip ran and found > regression (I don't think he got chance to confirm that) >
Have you by any chance tried to reproduce it at your end?
I did reproduce and verified that the new technique helps the case [1] (see last para). I did not go extra length to check if there are more cases which can still cause regression, like recheck is applied only once to each tuple (so the new technique does not yield any benefit) and whether that still causes regression and by how much. However I ran pure pgbench workload (only HOT updates) with smallish scale factor so that everything fits in memory and did not find any regression.
Having said that, it's my view that others need not agree to it, that we need to distinguish between CPU and IO load since WARM is designed to address IO problems and not so much CPU problems. We also need to see things in totality and probably measure updates and selects both if we are going to WARM update all tuples once and read them once. That doesn't mean we shouldn't perform more tests and I am more than willing to fix if we find regression in even a remotely real-world use case.
