On Tue, Mar 21, 2017 at 8:10 PM, Robert Haas <robertmhaas@gmail.com> wrote: > If the WAL writing hides the loss, then I agree that's not a big > concern. But if the loss is still visible even when WAL is written, > then I'm not so sure.
The tests table schema was taken from earlier tests what Pavan has posted [1], hence it is UNLOGGED all I tried to stress the tests. Instead of updating 1 row at a time through pgbench (For which I and Pavan both did not see any regression), I tried to update all the rows in the single statement.
Sorry, I did not mean to suggest that you set it up wrongly, I was just trying to point out that the test case itself may not be very practical. But given your recent numbers, the regression is clearly non-trivial and something we must address.
I have changed the settings as recommended and did a quick test as above in our machine by removing UNLOGGED world in create table statement.
Patch Tested : Only 0001_interesting_attrs_v18.patch in [2]
Response time recorded shows there is a much higher increase in response time from 10% to 25% after the patch.
Thanks for repeating the tests. They are very useful. It might make sense to reverse the order or do 6 tests each and alternate between patched and unpatched master just to get rid of any other anomaly.
BTW may I request another test with the attached patch? In this patch, we check if the PageIsFull() even before deciding which attributes to check for modification. If the page is already full, there is hardly any chance of doing a HOT update (there could be a corner case where the new tuple is smaller than the tuple used in previous UPDATE and we have just enough space to do HOT update this time, but I can think that's too narrow).
