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 1sFqQA-006f5H-DS for pgsql-general@arkaria.postgresql.org; Sat, 08 Jun 2024 07:23:27 +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 1sFqQ7-00Fvyw-7S for pgsql-general@arkaria.postgresql.org; Sat, 08 Jun 2024 07:23:24 +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 1sFqQ6-00Fvym-Oz for pgsql-general@lists.postgresql.org; Sat, 08 Jun 2024 07:23:23 +0000 Received: from mail-yw1-x1132.google.com ([2607:f8b0:4864:20::1132]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sFqQ0-000HHG-Oi for pgsql-general@lists.postgresql.org; Sat, 08 Jun 2024 07:23:22 +0000 Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-62ce7b3b8d9so537627b3.0 for ; Sat, 08 Jun 2024 00:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717831395; x=1718436195; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=OWJe4uNmjh8d2RqTwsVYuLdrqwVxqzr9SFU7ApGFc1w=; b=MPDmh2PSX24P1V/pU736ni9lHNCdRlYVhBeRsRjYGKjFYrK9jwT7M5u18j5IpZq2Gq dh3jh7/igDcOwdXZ9/E6483iJjWGsEnObBhMFZDXZzdJbrUYFiXYLCV7QUj5JjDxcnBm fq9ySkrrQ+KXiUREoPwGjYHe2/rXi8+dv6oAT6m9vuj9tFk6qRZO+qf1O2PTyFm9UVtc jUx0B+J8fmwGeT4TdGP/jm6DqLEEzdcTA/dhcIaW1ZnvOAx1mvhMY55fNZbjxMVhGr36 jOCdqlV4rONpmvmhqslYE4E1wMQtk7WSqDue8GHK8SH5ZsVNBtig9bYDSt5Cwo93194j x/Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717831395; x=1718436195; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=OWJe4uNmjh8d2RqTwsVYuLdrqwVxqzr9SFU7ApGFc1w=; b=cCf0H213QKF90v1dlVH5B1jsORLU8/2vAMDuC0r/JF9+RVkF1L1+Rd30voS4X35Y58 ZzLU0S1CK2aCJMIS3PIObeMH1V+iifdyjEUXJMVvLmthB+/tCoB5RNf9CcX7RUnZ4pXL c4EckHOkPUQ0m4kfWfTyiQfH8Q703fDbCCPPuD3Ii0/Rw8VVLaA63LGIUJsWJugk+tEC iSdhwHSankUJWsAbXomWoM+XxPCtu3b/Lgpq8jS8OEXdTd6kYgY4t2MjtNP7Qwh/24+N ZntVwhBZh5ED/GiptN7lwV4sbciKS+k7N4aUTXmV6mRexYA5m8vLepF1kxI1ZbwHWjIS juSQ== X-Gm-Message-State: AOJu0YzVvU2YnW0bhwH9NSszjepm7ZRZvUYZbrGAt/oSKQ2w75isUK7v T+gZWGt2mRL+LMvBZdMrV6b7CUJMb6XOUrNvKOI5AiW9tdUo/CukD6+wihutSxaMp8SNlYE5yyE 2RNeyx1QXm/tlKf2DFzAPzZBPy5ba1lQr X-Google-Smtp-Source: AGHT+IEkR4STNmvbk/GXvMpwGtYVZ+SEuhLr/9T9ReIi3jx4zc+Kt5UGijR9dOlSKRLqbP9EtE+slh+2P6xDvZvKOrU= X-Received: by 2002:a0d:df54:0:b0:61b:e5de:1206 with SMTP id 00721157ae682-62cd57030c1mr36655897b3.3.1717831395249; Sat, 08 Jun 2024 00:23:15 -0700 (PDT) MIME-Version: 1.0 From: Lok P Date: Sat, 8 Jun 2024 12:53:03 +0530 Message-ID: Subject: Creating big indexes To: pgsql-general Content-Type: multipart/alternative; boundary="000000000000191aa0061a5bcaea" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000191aa0061a5bcaea Content-Type: text/plain; charset="UTF-8" Hello, We have a few tables having size ~5TB and are partitioned on a timestamp column. They have ~90 partitions in them and are storing 90 days of data. We want to create a couple of indexes on those tables. They are getting the incoming transactions(mainly inserts) 24/7 , which are mostly happening on the current day/live partition. Its RDS postgres version 15.4. So in this situation Should we go with below i.e one time create index command on the table.. CREATE INDEX CONCURRENTLY idx1 ON tab(column_name); Or create index on individual partitions from different sessions, say for example create indexes on 30 partitions each from three different sessions so as to finish all the 90 partitions faster? CREATE INDEX CONCURRENTLY idx1 ON tab_part1(column_name); CREATE INDEX CONCURRENTLY idx1 ON tab_part2(column_name); ..... ..... Basically I have three questions: 1)If we can do this index creation activity online without impacting the incoming transactions or do we have to take down time for this activity? 2)If we can't do it online then , what is the fastest method to do this index creation activity ? 3)Should we change the DB parameters in a certain way to make the process faster? We have currently set below parameters max_parallel_workers-16 max_parallel_maintenance_workers-2 maintenance_work_mem- 4GB Regards Lok --000000000000191aa0061a5bcaea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
We have a few tables having size ~5TB and are p= artitioned on a timestamp column. They have ~90 partitions in them and are = storing 90 days of data. We want to create a couple of indexes on those tab= les. They are getting the incoming transactions(mainly inserts) 24/7 , whic= h are mostly happening on the current day/live partition. Its RDS postgres = version 15.4. So in this situation

Should we go with belo= w i.e one time create index command on the table..

CREATE INDEX CONC= URRENTLY idx1 ON tab(column_name);
Or
create index on individual par= titions from different sessions, say for example create indexes on 30 parti= tions each from three different sessions so as to finish all the 90 partiti= ons faster?
CREATE INDEX CONCURRENTLY idx1 ON tab_part1(column_name);CREATE INDEX CONCURRENTLY idx1 ON tab_part2(column_name);
.....<= /div>
.....

Basically I have three questions:
1)If we can do = this index creation activity online without impacting the incoming transact= ions or do we have to take down time for this activity?
2)If we can'= ;t do it online then , what is the fastest method to do this index creation= activity ?
3)Should we change the DB parameters in a certain way t= o make the process faster? We have currently set below parameters

ma= x_parallel_workers-16
max_parallel_maintenance_workers-2
maintenance_= work_mem- 4GB

Regards
Lok
--000000000000191aa0061a5bcaea--