On Tue, Apr 11, 2017 at 10:50 PM, Pavan Deolasee <pavan.deola...@gmail.com> wrote: > > > On Tue, Apr 11, 2017 at 7:10 PM, Robert Haas <robertmh...@gmail.com> wrote: >> >> >> >> Yes, and as Andres says, you don't help with those, and then you're >> upset when your own patch doesn't get attention. > > > I am not upset, I was obviously a bit disappointed which I think is a very > natural emotion after spending weeks on it. I am not blaming any one > individual (excluding myself) for that and neither the community at large > for the outcome. And I've moved on. I know everyone is busy getting the > release ready and I see no point discussing this endlessly. We have enough > on our plates for next few weeks. > >> >> >> Amit and others who have started to >> dig into this patch a little bit found real problems pretty quickly >> when they started digging. > > > 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. >> >> Those problems should be addressed, and >> review should continue (from whatever source) until no more problems >> can be found. > > > Absolutely. > >> >> The patch may >> or may not have any data-corrupting bugs, but regressions have been >> found and not addressed. > > > I don't know why you say that regressions are not addressed. Here are a few > things I did to address the regressions/reviews/concerns, apart from fixing > all the bugs discovered, but please let me know if there are things I've not > addressed. > > 1. Improved the interesting attrs patch that Alvaro wrote to address the > regression discovered in fetching more heap attributes. The patch that got > committed in fact improved certain synthetic workloads over then master. > 2. Based on Petr and your feedback, disabled WARM on toasted attributes to > reduce overhead of fetching/decompressing the attributes. > 3. Added code to avoid doing second index scan when the index does not > contain any WARM pointers. This should address the situation Amit brought up > where only one of the indexes receive WARM inserts. > 4. Added code to kill wrong index pointers to do online cleanup. > 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? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
