Message-ID: <a9b352e807b53ef04b307e1453399fd601bdf076.camel@cybertec.at>
Subject: Re: [HACKERS] Surjective functional indexes
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>,
  Konstantin Knizhnik <k.knizhnik@postgrespro.ru>, Stephen Frost
 <sfrost@snowman.net>, Michael Paquier <michael.paquier@gmail.com>, Alvaro
 Herrera <alvherre@alvh.no-ip.org>,  Christoph Berg <myon@debian.org>,
 Thomas Munro <thomas.munro@enterprisedb.com>, Peter Eisentraut
 <peter.eisentraut@2ndquadrant.com>, PostgreSQL Hackers
 <pgsql-hackers@postgresql.org>
Date: Thu, 08 Nov 2018 13:23:19 +0100
In-Reply-To: <25975.1541618754@sss.pgh.pa.us>
References: <aad81201-8788-a621-2001-537d843186fb@postgrespro.ru>
	 <20171214211553.ijxfd4p52nz7qg44@alvherre.pgsql>
	 <CAB7nPqR8GPni-Y_Tr1+6XFdYCuum8a5MuB9q2+hnVcA7BYrorw@mail.gmail.com>
	 <623fdf0f-c3d1-7553-e784-f8d5a900239b@postgrespro.ru>
	 <20180106225942.GT2416@tamriel.snowman.net>
	 <40fd1ef1-6227-69d1-9a24-edfef875e006@postgrespro.ru>
	 <20180301194824.46ivyszju2ivhlh5@alap3.anarazel.de>
	 <CA+TgmoZzdNsTFmmt+wTtCn0hQ+1F=OEG6ptbSRbi6prqVa97Cg@mail.gmail.com>
	 <20180511033227.vvgm3yi5xngro2hp@alap3.anarazel.de>
	 <CANP8+jKD+u-oW-whEdx1+k_NjAwHU4PvNse-qLp-o_d2zSXW7A@mail.gmail.com>
	 <20180511143737.rvogcsxdksrhyyj5@alap3.anarazel.de>
	 <CANP8+jLgdS-_ka5bhyG_=f5wGYVY-bQy3YD7rJY=TDnpA1snmg@mail.gmail.com>
	 <CA+Tgmob_qk-w38Mbp5wCCGH9G8AFpmB0K0aTLujJqHNbBpBNUA@mail.gmail.com>
	 <25975.1541618754@sss.pgh.pa.us>
Organization: Cybertec
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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