Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > On 2018-Nov-08, Konstantin Knizhnik wrote: >> Before doing any other refactoring of projection indexes I want to attach >> small bug fix patch which >> fixes the original problem (SIGSEGV) and also disables recheck_on_update by >> default. >> As Laurenz has suggested, I replaced boolean recheck_on_update option with >> "on","auto,"off" (default).
> I think this causes an ABI break for GenericIndexOpts. Not sure to what > extent that is an actual problem (i.e. how many modules were compiled > with 11.0 that are gonna be reading that struct with later Pg), but I > think it should be avoided anyhow. I do not see the point of having more than a boolean option anyway, if the default is going to be "off". If the user is going to the trouble of marking a specific index for this feature, what else is she likely to want other than having it "on"? The bigger picture here, and the reason for my skepticism about having any intelligence in the enabling logic, is that there is no scenario in which this code can be smarter than the user about what to do. We have no insight today, and are unlikely to have any in future, about whether a specific index expression is many-to-one or not. I have exactly no faith in cost-estimate-based logic either, because of the extremely poor quality of our function cost estimates --- very little effort has been put into assigning trustworthy procost numbers to the built-in functions, and as for user-defined ones, it's probably much worse. So that's why I'm on the warpath against the cost-based logic that's there now; I think it's just garbage-in-garbage-out. regards, tom lane