On Tue, Apr 11, 2017 at 10:50 PM, Pavan Deolasee
> 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.
>> 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
> 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?
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: