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 1sfLnF-005EKX-Iv for pgsql-general@arkaria.postgresql.org; Sat, 17 Aug 2024 15:56: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 1sfLnB-004RW2-R1 for pgsql-general@arkaria.postgresql.org; Sat, 17 Aug 2024 15:56:38 +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 1sfLnB-004RVt-EN for pgsql-general@lists.postgresql.org; Sat, 17 Aug 2024 15:56:38 +0000 Received: from mail-lf1-x129.google.com ([2a00:1450:4864:20::129]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sfLn8-0009V5-ID for pgsql-general@lists.postgresql.org; Sat, 17 Aug 2024 15:56:37 +0000 Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-53310adb4c3so3030092e87.3 for ; Sat, 17 Aug 2024 08:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723910194; x=1724514994; 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=GEO88ZRvLqkxAtBIDhzeZgIpZv8CWBdcMMfZGCSnfpQ=; b=YrHJNfWOGgqakKFP22/bb39QPDdIZpo0N08yhkboKTXuD9MkogfNy0yTayItkiuCHC B/tt/Qo8xSyHTHmTbXJ82FEywYigm/X1bsCkRqkRgTwdZRH8XdAqgMzI/364K4+eBNZW GwVXnpZborVHuPHMhSeM47KESt/2Cj5923uUWTca4V/h3G9ReCSC2YHyUNEG05Y3KlO/ cNUgWtvE/zw4kXtEgrKBbY0GLTfimP8gUw3h5d+wxwj27s25cKbWMYlaemav7mPOySgS oii0x4uMGdhhtOtG+WDcziucgcoTZM3ALMdgBTX7ahSQPyJ44t2vx/Tg5MzkYoAbQqfJ kQHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723910194; x=1724514994; 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=GEO88ZRvLqkxAtBIDhzeZgIpZv8CWBdcMMfZGCSnfpQ=; b=w4Ag0Wye30f+pizuCylUbUNkivG4rGe0Pq6hJ0EWk4ySYXfJ/OrI5mxq0NB3c5Ir1g AWQv3v0KHNH4liHxR5WS7gzrYVT7KiVre5RI61qOApqVSrLil01s/qOidLUCvxFdTLey 8RMrYStUhGSGmqcUG0BEMjLZNYDVZLbxzUWZsPtLKCo2Z/k4nXxuBgnqgbV6MdxIJBep O/X8+dMA29aaqmeE+hdRpIp6iydO4SVYFb+79CFpXms0XvdKKa0tq19FjPsytVf1qxrB RPkbiIaPRXDd6r7JonDwJ2qZsqryBv3CSObQPp8/Yu9sf+tk5oTrC4QqzOAqFhzuJY+6 Rt9A== X-Forwarded-Encrypted: i=1; AJvYcCWNKizAoZNx2uA4qQd0kbUGib1KVkf1DpqcUhON7Irw5A8zydT95bRkjdrMDijEESbq/ElSU0/MpPpVQpK/ew8Jd+myyeakVviZlaZaHIZuYAX9 X-Gm-Message-State: AOJu0YxchfHRyrWFSDUOI4q8JtlYmtv6w5U2ADBFYmgwy2TKCl9fjZwe CzVPOcJNPyFenV9+Us6QvGQyt41Im3JTyxj/JlKxoFXiYP6k+yYSxbQoZsgPQaGsnqtcwwmaArg BAJH6cd5/glx95ilckFdcQ6TZPZ8= X-Google-Smtp-Source: AGHT+IE5ZFY6wp1CQdHbg9cXU1ZbybuZgllHdojvePCy3LR2FJd5t0VU478ZsMyzYG1TbAIDMmZf1knaVjiUERnmsJQ= X-Received: by 2002:a05:6512:3d8f:b0:52c:c9bb:2ba4 with SMTP id 2adb3069b0e04-5331c6db15bmr4101002e87.46.1723910193751; Sat, 17 Aug 2024 08:56:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sabino Mullane Date: Sat, 17 Aug 2024 11:55:56 -0400 Message-ID: Subject: Re: Column type modification in big tables To: Lok P Cc: Alban Hertroys , sud , pgsql-general Content-Type: multipart/alternative; boundary="000000000000b92f3c061fe31e4a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000b92f3c061fe31e4a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 15, 2024 at 4:41=E2=80=AFPM Lok P wrote: > Additionally , if we are okay with the 7.5hrs of down time , is my > calculation/extrapolation of total time consumption based on a sample > table, for direct alter, accurate? Because, in that case , I was thinkin= g > it's less complex and also less error prone to just do it in a single alt= er > command rather than going for multiple steps of detach, alter, attach > partition. > Well, it's meant to get you a ballpark figure, but yes, it seems as though you will probably okay, But for something this critical involving production downtime, I would try out the exact command and see how long it takes on a test system. Restore a backup (you have backups I hope) or use pg_basebackup to make a copy of your prod system somewhere. Cheers, Greg --000000000000b92f3c061fe31e4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 15, 2024 at 4:41=E2=80=AFPM L= ok P <loknath.73@gmail.com&g= t; wrote:
Additiona= lly , if we are okay with the 7.5hrs of down time , is my calculation/extra= polation of total time consumption based on a sample table,=C2=A0 for direc= t alter, accurate? Because, in that case , I was thinking it's less com= plex and also less error prone to just do it in a single alter command rath= er than going for multiple steps of detach, alter, attach partition.
<= /div>

Well, it's meant to get you= a ballpark figure, but yes, it seems as though you will probably okay, But= for something this critical involving production downtime, I would try out= the exact command and see how long it takes on a test system. Restore a ba= ckup (you have backups I hope) or use pg_basebackup to make a copy of your = prod system somewhere.

Cheers,
Greg




=C2=A0
--000000000000b92f3c061fe31e4a--