On Tue, Mar 21, 2017 at 10:47 PM, Bruce Momjian <bruce@momjian.us> wrote:
On Tue, Mar 21, 2017 at 01:04:14PM -0400, Robert Haas wrote: > > I know we have talked about it, but not recently, and if everyone else > > is fine with it, I am too, but I have to ask these questions. > > I think that's a good question. I previously expressed similar > concerns. On the one hand, it's hard to ignore the fact that, in the > cases where this wins, it already buys us a lot of performance > improvement. On the other hand, as you say (and as I said), it eats > up a lot of bits, and that limits what we can do in the future. On > the one hand, there is a saying that a bird in the hand is worth two > in the bush. On the other hand, there is also a saying that one > should not paint oneself into the corner. > > I'm not sure we've had any really substantive discussion of these > issues. Pavan's response to my previous comments was basically "well, > I think it's worth it", which is entirely reasonable, because he > presumably wouldn't have written the patch that way if he thought it > sucked. But it might not be the only opinion.
Early in the discussion we talked about allowing multiple changes per WARM chain if they all changed the same index and were in the same direction so there were no duplicates, but it was complicated. There was also discussion about checking the index during INSERT/UPDATE to see if there was a duplicate. However, those ideas never led to further discussion.
Well, once I started thinking about how to do vacuum etc, I realised that any mechanism which allows unlimited (even handful) updates per chain is going to be very complex and error prone. But if someone has ideas to do that, I am open. I must say though, it will make an already complex problem even more complex.
I know the current patch yields good results, but only on a narrow test case,
Hmm. I am kinda surprised you say that because I never thought it was a narrow test case that we are targeting here. But may be I'm wrong.
