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 1seZOK-008tLZ-2X for pgsql-general@arkaria.postgresql.org; Thu, 15 Aug 2024 12:15:44 +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 1seZOI-00G6Am-0h for pgsql-general@arkaria.postgresql.org; Thu, 15 Aug 2024 12:15:42 +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 1seZOH-00G6Ad-FM for pgsql-general@lists.postgresql.org; Thu, 15 Aug 2024 12:15:41 +0000 Received: from mail-yb1-xb30.google.com ([2607:f8b0:4864:20::b30]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1seZOE-004rCJ-Nf for pgsql-general@lists.postgresql.org; Thu, 15 Aug 2024 12:15:40 +0000 Received: by mail-yb1-xb30.google.com with SMTP id 3f1490d57ef6-e116fca4175so35312276.1 for ; Thu, 15 Aug 2024 05:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723724137; x=1724328937; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dN0WxAD3DfXAdpC3AfWiY+r3V81xwyn8ibl4qURyegY=; b=T9NfM8AFTIZsO7fpXBtdRUS+gjFnJ9OC6eBLz8jb/IxacmsFUyutgSbcWtV6yRGC/4 PRrGooZPIpuFRs23rQVO+5e4IqjeYEVycP4DTsI8ngR4E/eHKuD0C7YJ19hAGnzrJh1L sEa480WMugW/QRKG5GdCzyDh8G79yI6o8IzYCFxaaSE+mcc/ELnNL1vi8pvs+HzigtpV 7JQLOr1DK35JTIn9bxwCWTORyeUH2uTX/G43tp8xCOkCRJnzcZ91yswq74q+5CuEnxWz PNRhZ/T2BaJ0izMIHS88koWX+lX4tDmumapRl2dE5OqG6vobfS5jY02h49iQDkWKXLN1 /j9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723724137; x=1724328937; h=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=dN0WxAD3DfXAdpC3AfWiY+r3V81xwyn8ibl4qURyegY=; b=e4Jm5RWhwJ72A1WkkEXq7MGdJjpnw4NoHGkoqjZuEcOyAp6Wi+Z4Ziz4UzTy6IhZIz X4H2z45OOcQjut82GmrkjL5KuUtZtE+RSp2hmgNPx2nGJfGcowQmlO0ADPT6Jk5V1m19 D6XQdT8n0/z0TkUKcI9T6hZm11XAPVCYryoWU9JeC+Bljcv8ILqamhjdVKdH4BdOf+q+ bmXFAzmTBMooIMQKrEvNm3XKRsKze5i0nVmT2f800UGr9zZHebMKlSX7HCOyoE9mvx86 fyI1gldxroaR6L+5O0LzJzuXTWrLWUjvUTvTEENW2jZkkY5m9RR90q5wqMasgJQGwMIK 5+FQ== X-Forwarded-Encrypted: i=1; AJvYcCVr3yyxLuHYA+zwa8fFFP4dftfaqGHFoTKGRMB1vz5hHjMOgDqk9pPeonS8+B8eQFKdEwBfBpcpopyHSW6B@lists.postgresql.org X-Gm-Message-State: AOJu0YzlV4GorAwlorMwZhyXnkNZFFDYZ+/EDwwKIX4vF2EJa4PksODN SX0RIC/cd58RUMHwUoeGDPwsktpRGa8T4YV99MGtCpgmRrHzhUsbjDH2wYxwOhod5iP8HqSy0g+ 8YrVWRay82JURQ7Z3yABVGoEyp0ftHQ== X-Google-Smtp-Source: AGHT+IFLlg6hXq/sLyuo29m0K5Zon6SUejzxDwQ8euLS6TgaQOtyTOsfnj93m+PO80XWr/qCqpjrA/bEZWtPxoRF0SE= X-Received: by 2002:a05:6902:260d:b0:e0b:3e67:dbc2 with SMTP id 3f1490d57ef6-e116f21223bmr1054961276.7.1723724137279; Thu, 15 Aug 2024 05:15:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Lok P Date: Thu, 15 Aug 2024 17:45:25 +0530 Message-ID: Subject: Re: Column type modification in big tables To: Greg Sabino Mullane Cc: sud , pgsql-general Content-Type: multipart/alternative; boundary="000000000000e4c014061fb7ccf3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e4c014061fb7ccf3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 13, 2024 at 7:39=E2=80=AFPM Greg Sabino Mullane wrote: > On Sat, Aug 10, 2024 at 5:06=E2=80=AFPM Lok P wrot= e: > > >> Can someone through some light , in case we get 5-6hrs downtime for this >> change , then what method should we choose for this Alter operation? >> > > We can't really answer that. Only you know what resources you have, what > risk/reward you are willing to handle, and how long things may take. For > that latter item, your best bet is to try this out on the same/similar > hardware and see how long it takes.* Do a smaller table and extrapolate > if you need to. * > Hello Greg, In terms of testing on sample data and extrapolating, as i picked the avg partition sizeof the table (which is ~20GB) and i created a non partitioned table with exactly same columns and populated with similar data and also created same set of indexes on it and the underlying hardware is exactly same as its on production. I am seeing it's taking ~5minutes to alter all the four columns on this table. So we have ~90 partitions in production with data in them and the other few are future partitions and are blank. (Note- I executed the alter with "work_mem=3D4GB, maintenance_work_mem=3D30= gb, max_parallel_worker_per_gather=3D8, max_parallel_maintenance_worker =3D16" = ) So considering the above figures , can i safely assume it will take ~90*5minutes=3D ~7.5hours in production and thus that many hours of downtim= e needed for this alter OR do we need to consider any other factors or activity here? --000000000000e4c014061fb7ccf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Aug 13, 2024 at 7:39=E2=80=AFPM G= reg Sabino Mullane <htamfids@gmail= .com> wrote:
On Sat, Aug 10, 2024 at 5:06=E2=80=AF= PM Lok P <lokn= ath.73@gmail.com> wrote:
=C2=A0=
Can someone through=C2=A0some light , in case= we get 5-6hrs downtime for this change , then what method=C2=A0should=C2= =A0we choose for this Alter operation?

We can't really answer that. Only you know what resou= rces you have, what risk/reward you are willing to handle, and how long thi= ngs may take. For that latter item, your best bet is to try this out on the= same/similar hardware and see how long it takes. Do a smaller table and= extrapolate if you need to.=C2=A0
<= br>
Hello Greg,=C2=A0

In terms of testin= g on sample data and extrapolating, as i picked the=C2=A0avg partition size= of the table (which is ~20GB) and i created a non partitioned table with ex= actly same columns and populated with similar data and also created=C2=A0sa= me set of indexes on it and the underlying hardware is exactly same as its = on production. I am seeing it's taking ~5minutes to alter all the four = columns on this table. So we have ~90 partitions in production with data in= them and the other few are future partitions and are blank. (Note- I execu= ted the alter=C2=A0with "work_mem=3D4GB, maintenance_work_mem=3D30gb, = max_parallel_worker_per_gather=3D8, max_parallel_maintenance_worker =3D16&q= uot; )

So considering the above figures , can i sa= fely assume it will take ~90*5minutes=3D ~7.5hours in production and thus t= hat many hours of=C2=A0downtime needed for this=C2=A0alter=C2=A0OR do we ne= ed to consider any other factors or activity here?=C2=A0
=C2=A0
--000000000000e4c014061fb7ccf3--