Re: Add column with default value in big table - splitting of updatescan help? - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Add column with default value in big table - splitting of updatescan help?
Date
Msg-id 35d595b3-958b-49f2-6727-f50f73fd831e@aklaver.com
Whole thread Raw
In response to Re: Add column with default value in big table - splitting of updatescan help?  (Durumdara <durumdara@gmail.com>)
List pgsql-general
On 1/31/20 5:43 AM, Durumdara wrote:
> Hello!
> 
> a.)
> PG version is mainly 9.6, but some of the servers are 10.x or 11.x.
> 
> b.)
> We have semi-automatic tool which get the a new modifications on 
> databases, and execute them at once by database.
> So one SQL script by one database, under one transaction - whole or 
> nothing. If something failed, we know where to we start again by hand. 
> It is impossible to execute only the first half, and we don't know which 
> one executed or not
> 
> The main problem that sometimes we have to modify some tables which have 
> too much records in some customer databases.
> 
> ---
> 
> As I think the best way to solve this:
> 
> 1.)
> Future goal: upgrade to PG 11.
> 
> 2.)
> We need to write a preprocessor code. If it finds "alter table" with 
> "add column" and "default", and it is "critical database", the whole 
> operation halts on that point, and warn us to "do it yourself"... :-)
> 
> ---
> 
> After the previous same problem on tk table I tried to write a client 
> app, which update records by 10000 with commit - but it was very slow.
> 
>     update tk set field1 = 'MUCH' where id in (
>        select id from tk where field1 is NULL limit 10000
>     )
> 
> I think this caused that in the goal field haven't got index (because 
> many times the fields with default values are not searchable, just row 
> level fields), and the client/server communication is slower than I like.
> 
> Formerly I thought I could speeding up this with stored proc - but as I 
> read the stored procs can't use inner transactions - so I must make 
> client programme to use begin/commit... (PGAdmin?).


Up to version 11 Postgres only had stored functions. With 11+ there are 
stored procedures and inner transactions:

https://www.postgresql.org/docs/11/plpgsql-transactions.html

In stored functions the best you can do is:

https://www.postgresql.org/docs/11/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING

> 
> Thanks for the prior infos!
> 
> Best regards
>     dd
> 
> 
> hubert depesz lubaczewski <depesz@depesz.com <mailto:depesz@depesz.com>> 
> ezt írta (időpont: 2020. jan. 30., Cs, 17:20):
> 
>     On Thu, Jan 30, 2020 at 04:51:02PM +0100, Durumdara wrote:
>      > Is there any advance when I split updates? I'm in one transaction.
> 
>     In this case - no. The benefit of split updates is when you're not in
>     single transaction.
> 
>     Why would you want to have it all done in single transaction?
> 
>     Best regards,
> 
>     depesz
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com



pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: How to restore to empty database
Next
From: Steven Lembark
Date:
Subject: Re: combination join against multiple tables