From: Tom Lane <tgl@sss.pgh.pa.us>
To: ruslan.ganeev@list.ru
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18166: 100 Gb 18000000 records table update
In-reply-to: <18166-8d0f3718572475ef@postgresql.org>
References: <18166-8d0f3718572475ef@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Fri, 20 Oct 2023 22:09:18 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <4020106.1697851360.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Fri, 20 Oct 2023 21:22:40 -0400
Message-ID: <4020107.1697851360@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4020107.1697851360%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> We tried to make a script, which sets enddate = '2022-12-31' for all
> records, having the value in «DataVip» that is not maximal.  For other
> records the script set s enddate = null
> The problem is that the script is running for 6 hours, the main percentage
> of time is taken by the rebuilding of indexes.

This is not a bug.  However ... a common workaround for bulk updates
like that is to drop all the table's indexes and then recreate them
afterwards.  It's often quicker than doing row-by-row index updates.

			regards, tom lane