Re: [HACKERS] Surjective functional indexes

On 08.11.2018 15:23, Laurenz Albe wrote:
> Tom Lane wrote:
>> I wanted to enumerate my concerns while yesterday's
>> events are still fresh in mind.  (Andres or Robert might have more.)
>>
>> * I do not understand why this feature is on-by-default in the first
>> place.  It can only be a win for expression indexes that are many-to-one
>> mappings; for indexes that are one-to-one or few-to-one, it's a pretty
>> big loss.  I see no reason to assume that most expression indexes fall
>> into the first category.  I suggest that the design ought to be to use
>> this optimization only for indexes for which the user has explicitly
>> enabled recheck_on_update.  That would allow getting rid of the cost check
>> in IsProjectionFunctionalIndex, about which we'd otherwise have to have
>> an additional fight: I do not like its ad-hoc-ness, nor the modularity
>> violation (and potential circularity) involved in having the relcache call
>> cost_qual_eval.
> That was my impression too when I had a closer look at this feature.
>
> What about an option "hot_update_check" with values "off" (default),
> "on" and "always"?
>
> Yours,
> Laurenz Albe
>
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).

-- 
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company