On Tue, Mar 21, 2017 at 11:45:09PM +0530, Pavan Deolasee wrote: > 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.
Yes, that is where we got stuck. Have enough people studied the issue to know that there are no simple answers? > 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. Well, it is really a question of how often you want to do a second WARM update (not possible) vs. the frequency of lazy vacuum. I assumed that would be a 100X or 10kX difference, but I am not sure myself either. My initial guess was that only allowing a single WARM update between lazy vacuums would show no improvementin in real-world workloads, but maybe I am wrong. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
