Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1spJTw-000ZeG-3v for pgsql-general@arkaria.postgresql.org; Sat, 14 Sep 2024 03:29:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1spJTv-0020tW-Ml for pgsql-general@arkaria.postgresql.org; Sat, 14 Sep 2024 03:29:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1spJTv-0020tN-BS for pgsql-general@lists.postgresql.org; Sat, 14 Sep 2024 03:29:55 +0000 Received: from mail-yb1-xb2f.google.com ([2607:f8b0:4864:20::b2f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1spJTs-0013ml-KX for pgsql-general@lists.postgresql.org; Sat, 14 Sep 2024 03:29:54 +0000 Received: by mail-yb1-xb2f.google.com with SMTP id 3f1490d57ef6-e1a90780f6dso2460148276.0 for ; Fri, 13 Sep 2024 20:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726284592; x=1726889392; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=4V20cQN/+g5/GlyD9hrx6FaizLX16b2c8q0a48t+ywU=; b=Hh90nplRRpfty5qYJMz/oM9msf42s2eUS/gizgsvor6rETtfPVErYvrTMZ+ocUvRHa qDQGCbHTXTX0jZtWH++kxhrOSAG/tpbe58LQnxI/e22AgrY6YeDmM5LV70KAQKLeSV/a KjteA/ZLzCqQ9r72qqHC6MKrrtCllhW8Nr5bZ7aT4MAY9GL7k6giv97qd5IC6HGtusSg gJjWsodB4nwQ1MfFKNfNPRdIEGmEnFqsOZUg5zRgwUcWYB3YjI1UASTekhGsCUcWGywS IebiOgDDAjShh0UI7WOGlRwx0nsaBcweatq4Ht1pJt2Hqdx6s7aVetOFi9o9AeHijfOM YEDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726284592; x=1726889392; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=4V20cQN/+g5/GlyD9hrx6FaizLX16b2c8q0a48t+ywU=; b=TfZ2HZyAmeA+HW+/CQLC8skfcA0iaf+H1sFChLc/2ucKLUE692XV6Dq7xCGODPsrT9 G+s8gfX5xZ6ETRH16EOH1/GUNMvYWG+tt+UjPdvKJgc5abFc1OUwA5NyBbjFM8lIOrG6 MPGXQcNHiyV+YYgfz4gI5oRqpQ8gYU2zI7ytYiIEnKtHZrr+s/srk1xCcAB8Z8puTiyU WOUAozV3TWE/a9A5awp9ASQquMCMswcuLCmR0H1FGwMyhC8NmxMCriHZJt3eb6U5AHwP YvzPR4kDqSRYu8pcEd3RIDMxJtKBK0ZZdP/UNocrHw/6BIwSxa+qXENGTlm4/NCJB6EV TUGA== X-Gm-Message-State: AOJu0YxJSRXQ3FAD7OETWWxJJC+4zvcI7hSc+i+yQe17D9Asptw2vloI QlTZ4mZh/hDliHQvngSiVr/Zi73iedzrlPTwzEj0dyMX6O0ZADgcIA2cELaJ5fnl1Lz4M835mSo WMPsy/Z27z3Hj2gwNXUebdxeIvQI= X-Google-Smtp-Source: AGHT+IGdO0ZIJ3GuCLOhL5PUg0usR/h5XL5lcpnSol2glh0J5bx9blYWw2nPfM2zBbBe5Li7UnQnvn+KrsdS347Iybs= X-Received: by 2002:a05:6902:260b:b0:e1a:8857:96dd with SMTP id 3f1490d57ef6-e1d9dbdbacamr7371938276.31.1726284592100; Fri, 13 Sep 2024 20:29:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Igor Korot Date: Fri, 13 Sep 2024 22:29:12 -0500 Message-ID: Subject: Re: update faster way To: yudhi s Cc: pgsql-general Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hii, On Fri, Sep 13, 2024 at 10:22=E2=80=AFPM yudhi s wrote: > > Hello, > We have to update a column value(from numbers like '123' to codes like 'a= bc' by looking into a reference table data) in a partitioned table with bil= lions of rows in it, with each partition having 100's millions rows. As we = tested for ~30million rows it's taking ~20minutes to update. So if we go by= this calculation, it's going to take days for updating all the values. So = my question is > > 1) If there is any inbuilt way of running the update query in parallel (e= .g. using parallel hints etc) to make it run faster? > 2) should we run each individual partition in a separate session (e.g. fi= ve partitions will have the updates done at same time from 5 different sess= ions)? And will it have any locking effect or we can just start the session= s and let them run without impacting our live transactions? Do you have any indexes? If not - you should, if yes - what are they? Thank you. > > UPDATE tab_part1 > SET column1 =3D reftab.code > FROM reference_tab reftab > WHERE tab_part1.column1 =3D subquery.column1; > > Regards > Yudhi