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 1sbeXk-000Vxt-NO for pgsql-general@arkaria.postgresql.org; Wed, 07 Aug 2024 11:09:24 +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 1sbeXi-006RVW-HP for pgsql-general@arkaria.postgresql.org; Wed, 07 Aug 2024 11:09:22 +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 1sbeXi-006RVN-5L for pgsql-general@lists.postgresql.org; Wed, 07 Aug 2024 11:09:22 +0000 Received: from mail-yb1-xb31.google.com ([2607:f8b0:4864:20::b31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sbeXf-003cQI-MF for pgsql-general@lists.postgresql.org; Wed, 07 Aug 2024 11:09:21 +0000 Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-e05ea5b87b1so83678276.3 for ; Wed, 07 Aug 2024 04:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723028958; x=1723633758; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=/iOQv+WU5jZxYlFqJZ21wDw6fmsOj08EG7QgINgI+kU=; b=OnRKNGOuBe+65uKk/fLveEUbCY5BxSeMRpbAHc/l7y0nAy4k9+Akw3XqWDs/nqOAN2 n+DY54kyX25US5buShqpS9F1lbY27Dlj67VvboR5y6Uljrl5Vam3BVQu3y3s6maAbNR9 +nomfdWsyz+a7b52ckp+G94RmNCecaLP+S60wUEc0jHxAGEJbV2y5/ifUVWywlkYHEWW 6Q+SiaQ6xf5BsiJ1tcpHhnrg0sm/965ps3GtA4gyDLCDk+v0zq8WM9ZNrF7WyLnF3Yxi IBG1lTcwZLzu7i6FXaZwFpFXJo5lheDHx40asYsfy3LuffrCbUX6NYPpAv5dJ3iV+Jg/ Dz0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723028958; x=1723633758; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=/iOQv+WU5jZxYlFqJZ21wDw6fmsOj08EG7QgINgI+kU=; b=G3iAZf1c1qW7hDXNvU5pw+RL+ESzhHifPht9F5oZRfWChizSSbj9rGXPB4EmCSrTmf M53G4LLP+4fV/PTePv3xjJm6T7U2MyoNPCn85wES6BRs2wEfZvIH3vSUDKun2goEaF23 fI0fqeryCdmH9qPIWprWXHFqfjdRpq7m3snrUWLNAhI546qX2jJ/BtHBlLo9EttgZcUU Oy2dy+LZFcufKyfNOIouwBOCZzCajfh1v6s8uNPlBBKpJ4JVRV95IoDt+swtuCvYGlXA Nc3aGKorlFNBMVbYnjps0y0dhbQNV/9/LyPZnm/ziQiXtg5X/JUZpqLxeEO3O6EL+rWy 1qRA== X-Gm-Message-State: AOJu0YxhFI65A+69IKBQYC1YioUkrQ9dXLmsgQX+cS2vpcLS3dhdhVZb Drp8vVspksWJoBCBFk43gHFFmepCmhNjl9AXtvlKfgcPiHrVkobyRicJP1a62GItoZpcyP0CHQC fc0E6BBT/5HGdW5WkB6xwB/zkzKBCE++7 X-Google-Smtp-Source: AGHT+IG1+J0Csd+CjHs4NYPzxL4CSu/xFyr7RxX6+LsTpBj4hCFDh4NiPY1nW1bXJz6zel9rCsJjgbvBD9RMH7Ufaac= X-Received: by 2002:a25:2e4d:0:b0:e0b:d2ea:d991 with SMTP id 3f1490d57ef6-e0bde2681cemr11668102276.3.1723028957811; Wed, 07 Aug 2024 04:09:17 -0700 (PDT) MIME-Version: 1.0 From: Lok P Date: Wed, 7 Aug 2024 16:39:05 +0530 Message-ID: Subject: Column type modification in big tables To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000f7e0ba061f15f00f" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000f7e0ba061f15f00f Content-Type: text/plain; charset="UTF-8" Hello all, We have a postgres table which is a range partitions on a timestamp column having total size ~3TB holding a total ~5billion rows spanning across ~150 daily partitions and there are ~140+columns in the table. Also this table is a child to another partition table. And we have partition creation handled through pg_partman extension on this table. We have a requirement of modifying the existing column lengths as below . So doing it directly through a single alter command will probably scan and rewrite the whole table which may take hours of run time. So trying to understand from experts what is the best possible way to tackle such changes in postgres database? And if any side effects we may see considering this table being child to another one and also dependency with pg_partman extension. two of the columns from varchar(20) to numeric(3) one of the columns from varchar(20) to varchar(2) one of the columns from Number(10,2) to Numeric(8,2) Regards Lok --000000000000f7e0ba061f15f00f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,
We have a postgres table which is a range p= artitions on a timestamp column having total size ~3TB holding a total ~5bi= llion rows spanning across ~150 daily partitions and there are ~140+columns= in the table. Also this table is a child to another partition table. And w= e have partition creation handled through pg_partman extension on this tabl= e.

We have a requirement of modifying the existing column lengths as= below . So doing it directly through a single alter command will probably = scan and rewrite the whole table which may take hours of run time.

= So trying to understand from experts what is the best possible way to tackl= e such changes in postgres database? And if any side effects we may see con= sidering this table being child to another one and also dependency with pg_= partman extension.

two of the columns from varchar(20) to numeric(3= )
one of the columns from varchar(20) to varchar(2)
one of the column= s from Number(10,2) to Numeric(8,2)

Regards
Lok
--000000000000f7e0ba061f15f00f--