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

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Klaudie Willis <Klaudie.Willis@protonmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: When Update balloons memory
Date: Tue, 14 Dec 2021 14:33:47 -0500
Message-ID: <377324.1639510427@sss.pgh.pa.us> (raw)
In-Reply-To: <CAH2-Wzm54LA8EeOf6-cFZCHwigZ0YgQVgcmuyFr=b8w2pzQgzA@mail.gmail.com>
References: <wJYzIcLjhFnsbCK8sy4lZZAojx7m04FwjsGF4WbrKj0gj2wLpaycQSEN1mtBUlhSAQGRvEdxZTwWRNV39UevSNWg8-h-tvWAL61pV4IuhW4=@protonmail.com>
	<3484560.1638889073@sss.pgh.pa.us>
	<YAjwxLJ1p4do7V4OkzpgwXrfV-fywioBsfvFaHnuY1Hbe-NjM0tsaCpJ_-KXwvFKF2YsQzQLCnFFFlMnyzd6TJ9UcXnQpcZfdZ1ZDcCqXIE=@protonmail.com>
	<189763.1639437451@sss.pgh.pa.us>
	<lviv_r7tA44gnx3rRU8VYdseWJLx-AzQCbsgdyz2-1Lse9ZmqDeLnzfDkBTut26kxlPZ8FX36TiKmCtXi5gAfhI-JVu-2n8fu7Dcta0Y3Ek=@protonmail.com>
	<261065.1639497535@sss.pgh.pa.us>
	<CAH2-Wzm54LA8EeOf6-cFZCHwigZ0YgQVgcmuyFr=b8w2pzQgzA@mail.gmail.com>

Peter Geoghegan <pg@bowt.ie> writes:
> Are you sure that it would really be worth the trouble of caching our
> answer? It's not clear that that has only minimal maintenance burden.

I'd be inclined to do so if we can find a suitable place to put it.
But wouldn't a field in IndexInfo serve?  Letting the field default
to "not optimizable" would cover most cases.

> The fact is that most individual aminsert() calls that get the hint
> will never actually apply it in any way.

Yeah, you could make an argument that just not trying to optimize when
there are index expressions would be fine for this --- and we may have
to fix it that way in v14, because I'm not sure whether adding a field
in IndexInfo would be safe ABI-wise.  But ISTM that the overhead of
index_unchanged_by_update is a bit more than I care to pay per row
even when it's only considering plain index columns.  I'm generally
allergic to useless per-row computations, especially when they're
being added by an alleged performance improvement.

Another thing we ought to check into is the extent to which this
is duplicative of the setup calculations for HOT updates --- I seem
to recall that there's already roughly-similar logic somewhere else.

And, not to be too picky, but does this cope with the case where
an indexed column is changed by a BEFORE trigger, not by the
query proper?

			regards, tom lane





view thread (22+ messages)  latest in thread

Message-ID: <377324.1639510427@sss.pgh.pa.us>
Permalink:  ../377324.1639510427@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/377324.1639510427@sss.pgh.pa.us

 · 

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-bugs@postgresql.org
  Cc: tgl@sss.pgh.pa.us, pg@bowt.ie, Klaudie.Willis@protonmail.com, pgsql-bugs@lists.postgresql.org
  Subject: Re: When Update balloons memory
  In-Reply-To: <377324.1639510427@sss.pgh.pa.us>

* 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