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 1sdxfF-002eQH-HX for pgsql-general@arkaria.postgresql.org; Tue, 13 Aug 2024 19:58:41 +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 1sdxfE-006DAu-6r for pgsql-general@arkaria.postgresql.org; Tue, 13 Aug 2024 19:58:40 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sdxfD-006DAm-S7 for pgsql-general@lists.postgresql.org; Tue, 13 Aug 2024 19:58:39 +0000 Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sdxfB-004hep-M6 for pgsql-general@lists.postgresql.org; Tue, 13 Aug 2024 19:58:39 +0000 Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a7de4364ca8so620442366b.2 for ; Tue, 13 Aug 2024 12:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723579117; x=1724183917; 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=IEpgDGs1lp5UZsuUtg51zyQqXB2utZxsm3g2+zydoxA=; b=R3Eh0BXcwzkpmDMGoYKtdl2p83+kxB65XzvwZMkzfUENPd0FpG1GWnjUsZsPxtPloa uvP+NrYpi9FfCIGVphln9ets2U7QfRf7CkS0/TIgZA+eDZ7HJQ0dQLOgwLl4o1nWrSkL RNREX6LqVKNP1RFsMAHoFFz0wDNIWk7hYj53PJm4VSeIwFuOB5OdKG/K7i5yaV74DZ/c mNkMofJQZQBDC/UECbrz4XhCl/HzmOymD9h205Sg8SxRy02JeE0k7CIMmKb02X821vJK 91whAdFL5wQcpPEjEtM+NRfyJwcSuf2a1Vj7yKlsNO3ycMhMSX+eNQ48qyDApt9gcYY3 q4/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723579117; x=1724183917; 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=IEpgDGs1lp5UZsuUtg51zyQqXB2utZxsm3g2+zydoxA=; b=DO9wYizSOnoX5nCajrN5HAUB8uIyn/OEk+PqDM84RgKp0x1eTXO3pUXFwj0F7M0Axo Xi4jsoXO66rhXCfIZ9LEV2ABgM1gx5Nf7bCVZYPhU83sP+p2oZJoo2WEPvnWd4XaYU/k DzcyXxjZudcKbq1Lwo4VwaRX4dnB/99vhy3i1X286hLFdxQXOxrzbjMraJF6cFc2cSwy hpH+gSGIIKXnv1Q3pDQPvkOCB5yJgJZE56mYel3FPv96L8RBSlYRdUyJzaGLrquQyurZ kB5UPAUJXr0pCmyCXfcmsRwI6/LXAB/Ar1FEl9uV1KHNUZXqi2kh635k6bjPRanr1pdd SrSw== X-Forwarded-Encrypted: i=1; AJvYcCXWYQGSqPRL863o3eJcKLgtRQwaAzMwiqX1rWqI7YQ9T74Vv+D9MtjHGRNwDt9L4R4fzRmPrxf3/Mgn9R9eMg0gjdGUp1vCT1Q+teThBpBFFD/q X-Gm-Message-State: AOJu0YwZX/6duGOin+fSrDtnYW8SHTAuiieXiCYjRJwKKbdPI9i9CC7d RLkbxRno+E34QfpNV+iBkufy3CRmHQrKerwahDCaO/2XUBML1muPwXdw9kF3etBHHhngJlY5HDj 60aj9n/o9cBVdwObYpHWaFlzQeVo= X-Google-Smtp-Source: AGHT+IEAHsQtTftnWKozmFSUhUdSTqsTjpfwzM2sNjxQy/53rOx6z74ulE0X3BD/bVUH4u5t+Z9ytm0an2afZD8oWTQ= X-Received: by 2002:a17:907:f7a4:b0:a7d:3de1:4abd with SMTP id a640c23a62f3a-a8366d45fd6mr36302766b.39.1723579116408; Tue, 13 Aug 2024 12:58:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: veem v Date: Wed, 14 Aug 2024 01:28:24 +0530 Message-ID: Subject: Re: Column type modification in big tables To: Greg Sabino Mullane Cc: Lok P , sud , pgsql-general Content-Type: multipart/alternative; boundary="000000000000f9dafe061f960856" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f9dafe061f960856 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 13 Aug 2024 at 19:39, 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. Or promote one of your replicas offline and modify that. I'v= e > given you a low-risk / medium-reward option with check constraints, but f= or > the ALTER TABLE options you really need to try it and see (on non-prod). > >> >> What about if the OP opt a strategy something as below, 1) Detaching the partitions 2)Altering individual partitions with required column type and length 3)Altering the table 4)Attaching the partitions back to the main table This should be faster and also a controlled fashion for each partition individually. --000000000000f9dafe061f960856 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, 13 Aug 2024= at 19:39, Greg Sabino Mullane <ht= amfids@gmail.com> wrote:
On Sat, Aug 10, 2024 at 5= :06=E2=80=AFPM Lok P <loknath.73@gmail.com> wrote:
=C2=A0
Can someone through=C2=A0some lig= ht , 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 kno= w 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 thi= s out on the same/similar hardware and see how long it takes. Do a smaller = table and extrapolate if you need to. Or promote one of your replicas offli= ne and modify that. I've given you a low-risk / medium-reward option wi= th check constraints, but for the ALTER TABLE options you really need to tr= y it and see (on non-prod).


What about= if the OP opt a strategy something as below,
1) Detaching the par= titions 2)Altering individual partitions=C2=A0with required column type and= length 3)Altering the table 4)Attaching the partitions back to the main ta= ble

This should be faster and also a control= led fashion for each partition individually.=C2=A0
--000000000000f9dafe061f960856--