pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Konstantin Knizhnik <k.knizhnik@postgrespro.ru>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Christoph Berg <myon@debian.org>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Surjective functional indexes
Date: Thu, 08 Nov 2018 13:23:19 +0100
Message-ID: <a9b352e807b53ef04b307e1453399fd601bdf076.camel@cybertec.at> (raw)
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>

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





view thread (99+ messages)  latest in thread

Message-ID: <a9b352e807b53ef04b307e1453399fd601bdf076.camel@cybertec.at>
Permalink:  ../a9b352e807b53ef04b307e1453399fd601bdf076.camel@cybertec.at/
Also on:    postgresql.org/message-id/a9b352e807b53ef04b307e1453399fd601bdf076.camel@cybertec.at

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: laurenz.albe@cybertec.at, tgl@sss.pgh.pa.us, simon@2ndquadrant.com, robertmhaas@gmail.com, andres@anarazel.de, k.knizhnik@postgrespro.ru, sfrost@snowman.net, michael.paquier@gmail.com, alvherre@alvh.no-ip.org, myon@debian.org, thomas.munro@enterprisedb.com, peter.eisentraut@2ndquadrant.com
  Subject: Re: [HACKERS] Surjective functional indexes
  In-Reply-To: <a9b352e807b53ef04b307e1453399fd601bdf076.camel@cybertec.at>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox