Re: Optimize update of tables with generated columns

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Optimize update of tables with generated columns
Date: 2020-02-17 15:16:40
Message-ID: f7f78f54-d984-da56-0df1-963cc2d2e736@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-02-13 16:16, Pavel Stehule wrote:
> čt 13. 2. 2020 v 14:40 odesílatel Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com
> <mailto:peter(dot)eisentraut(at)2ndquadrant(dot)com>> napsal:
>
> On 2019-12-21 07:47, Peter Eisentraut wrote:
> > When updating a table row with generated columns, we only need to
> > recompute those generated columns whose base columns have changed in
> > this update and keep the rest unchanged.  This can result in a
> > significant performance benefit (easy to reproduce for example with a
> > tsvector column).  The required information was already kept in
> > RangeTblEntry.extraUpdatedCols; we just have to make use of it.
> >
> > A small problem is that right now ExecSimpleRelationUpdate() does not
> > populate extraUpdatedCols.  That needs fixing first.
>
> Here is an updated patch set that contains a fix for the issue above
> (should be backpatched IMO) and the actual performance patch as before.
>
>
> + 1
>
> I tested check-world without problems, and changes of patch has sense
> for me.

committed, thanks

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2020-02-17 15:35:25 Re: pgindent && weirdness
Previous Message Ants Aasma 2020-02-17 15:04:35 Re: Parallel copy