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.96) (envelope-from ) id 1w7Mkx-005EAj-39 for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2026 00:14:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w7Mkw-007KRW-1d for pgsql-hackers@arkaria.postgresql.org; Tue, 31 Mar 2026 00:14:54 +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.96) (envelope-from ) id 1w7Mkv-007KRM-3A for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2026 00:14:54 +0000 Received: from mail-vk1-xa2f.google.com ([2607:f8b0:4864:20::a2f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w7Mku-00000001t4h-0KX8 for pgsql-hackers@lists.postgresql.org; Tue, 31 Mar 2026 00:14:53 +0000 Received: by mail-vk1-xa2f.google.com with SMTP id 71dfb90a1353d-56cfe7b2344so1765399e0c.2 for ; Mon, 30 Mar 2026 17:14:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774916091; cv=none; d=google.com; s=arc-20240605; b=cAZkNqArVatbiLnpBMiqYzoJbodB2tUrANgDjfrXCBUUE2k7YbYdHD4krZppDJNv1u S9Ywr18Ar4lKr+/IHdBkJrM8ANOac4KYtOLyAIAx56wQ9xprp3OyrCvPaGb+QNWaew+L 6+NJ47uOkfR0LHs/asQqaOLMCcuScuN0H2nwIwwGVba6rfby9OSzGV1eclmoPFlFokdG 2koBgdeOXcd3iN3NGMYnd9iy4StLbDtI9r6NNZdUgBbD7F8BCJOUEuuWgm7+lqBEqjUa IPIOem0pZBkqQcRtjNaigq9mcYbLMTBfRucdz4XR62kDDUnxiA+Ybwi6RLgMHk7jZ3hA a6WA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=AGYnZ1ABjO7vU3XqSdTNbzcSJnpCesw4WwAfdcbbxHI=; fh=DLD5ea9Jbsp+uxKWZulIh+Z89yU3HPB6VJWSIpbb5mE=; b=PdLWUhU198Z54B0F5+KIg9soyy4I5/YUs7KeYFg68+G/tga7wwpX065M72zBx5TX5E NbOWDXQTAhwF1lsW0XxOedi8ucgS1VJ1udwAraz1V4bKo1R/mgkw7g2Ua745mBN3a1KW KyikliJspv3ViAbK9t0XX86jnSY3f9rICOkUL1+c32G/x7ZWvwLA+DGXqz+1qPoh5MI2 DccEKqUwJqi+4gS+Sw81TP6qESfssXBCrky94izfMLlDdC0aOuwDad0zBjOwkn53lQRA oPwBxte1JzE4lAcZ0ZEKZsHIRRJ+flY8jdPZmOwq3G24YL8tA/mtqXLeWDR05TDJFiJD Fr9Q==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774916091; x=1775520891; 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=AGYnZ1ABjO7vU3XqSdTNbzcSJnpCesw4WwAfdcbbxHI=; b=h4iyAXoVWCo/p/7XVBSxYilgnPmViECe6TntyYPv9NCDoB0mCzpnL2VATu7z+gYvQs TMuWVdrGTuGKHPVZwK+zepg2mSskyPBZ2xOev0nu0KyiE0tkF2KiHZUI6LLJw1i3QeM+ RS1lpyK9BybFupS0xFfafRTWN0F1LlRn02hDjgdZc3SPO9LCIZBvzQp9qDXdUsXrMUIa M0LiSarHc3Vx7CYNlVXHhS+dW6joxUlshx6xDkfVNfoV4VT0RtqL07xb9qGOdLIADGHV 3xY2yJshvnmvMKYSnafxiVmZtfD5wVu2kTs8BOOr5I1p5+ttiI4D4r8dzrYM6lp2k/Dp 3Hfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774916091; x=1775520891; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AGYnZ1ABjO7vU3XqSdTNbzcSJnpCesw4WwAfdcbbxHI=; b=jk5vHLYTzppFdjlDC8zZeq8EnxbL6qYgdlgdZzUoRIw3XmRC/9jfD176ag2kYSu91j OYBTITW9Up6tGgUBy4LIrCspzOmUHVT1bV4MmU/7Xsbd3LRjsyPBEhQ5QU1Ekn7QyISq UOBgoC9+LFG+09zfgJn++ap56XQvlT/QHHrEt2DbaTzeYVugDF9wgykq/8aFokLUhVlF SjYEDry2rehgAsmYAFGdLcEoH0JPw45Klwwaw6jJiEbkh0Lg+Vb8w78MmlQ29K9wsGIX THZlHcNsuSSMGvYHJMJG+Z0vqnHta2+46TxpzV0TarlSLU/NLfrvi5SJNxDeQESFBAFr lJwg== X-Forwarded-Encrypted: i=1; AJvYcCUUFcEyQ30gQTd8T8fW4updE3PrMgl1C0e/BvH8c6AIa/NAfH4aV0jMmkipFIDO8k4GpgBrl/xzNndexLLi@lists.postgresql.org X-Gm-Message-State: AOJu0YyooZaJb92SFW3nNzvM59tFASoAkgOAtAbIAabDvueSplzj0b/s Y2TkUb9ecSeej97U6P0Z5kUGvJtufvEO5UWwQwBtkR6JIOPgy9g/S23+LWnbVlIo/3ZJ2pMdOwt 9N+u5k/7q6MuvN/cY1RbvboPc/NHOHH0= X-Gm-Gg: ATEYQzzp60S6lf14agCYAcTqaCfAeJaqGzFU5lDaDm/S7MFubipb//BvKyRGzTLGhZ7 VWtyCd4at7PPIA8mnd5dkXbpwfSgGm0EvN6/ACplcKp8/BgMsAR1qJoD0aD71WfyGSFm2Qz7iC1 gFmR/U0tvj/uuz0mWbQkGFiJYIWtLnn3FdKdhCa8G7X6r1mLASzRbOdM+2ZgI9vBJUnkZk3I7Hk hKgtJ9RrqPhlLYrRGUm8v0NgOYwIUWHT7hg9mslkLTBkVr2Zgik65lhbFFc8xpc9Emh67l2nJt4 e5Fv+Sziyt9hhLEpjg== X-Received: by 2002:a05:6122:20a7:b0:56b:8023:b89e with SMTP id 71dfb90a1353d-56d4a51963fmr5411857e0c.6.1774916091271; Mon, 30 Mar 2026 17:14:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: SATYANARAYANA NARLAPURAM Date: Mon, 30 Mar 2026 17:14:39 -0700 X-Gm-Features: AQROBzAHwpQDXiP_H4Ci-xxLEXe6JBUCPNbVebZ2pLTB4FAsb2IAiMRdXqm08LE Message-ID: Subject: Re: POC: Parallel processing of indexes in autovacuum To: Daniil Davydov <3danissimo@gmail.com> Cc: Bharath Rupireddy , Masahiko Sawada , Sami Imseih , Alexander Korotkov , Matheus Alcantara , Maxim Orlov , Postgres hackers Content-Type: multipart/alternative; boundary="000000000000205d47064e46dbfb" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000205d47064e46dbfb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi On Mon, Mar 30, 2026 at 1:44=E2=80=AFAM Daniil Davydov <3danissimo@gmail.co= m> wrote: > Hi, > > On Mon, Mar 30, 2026 at 7:17=E2=80=AFAM SATYANARAYANA NARLAPURAM > wrote: > > > > Thank you for working on this, very useful feature. Sharing a few > thoughts: > > > > 1. Shouldn't we also cap by max_parallel_workers to avoid wasting DSM > resources in parallel_vacuum_compute_workers? > > Actually, autovacuum_max_parallel_workers is already limited by > max_parallel_workers. It is not clear for me why we allow setting this GU= C > higher than max_parallel_workers, but if this happens, I think it is a > user's > misconfiguration. > > > 2. Is it intentional that other autovacuum workers not yield cost limit= s > to the parallel auto vacuum workers? Cost limits are distributed first > equally to the autovacuum workers. > > and then they share that. Therefore, parallel workers will be heavily > throttled. IIUC, this problem doesn't exist with manual vacuum. > > If we don't fix this, at least we should document this. > > Parallel a/v workers inherit cost based parameters (including the > vacuum_cost_limit) from the leader worker. Do you mean that this can be t= oo > low value for parallel operation? If so, user can manually increase the > vacuum_cost_limit reloption for those tables, where parallel a/v sleeps t= oo > much (due to cost delay). > > BTW, describing the cost limit propagation to the parallel a/v workers is > worth mentioning in the documentation. I'll add it in the next patch > version. > > > 3. Additionally, is there a point where, based on the cost limits, > launching additional workers becomes counterproductive compared to runnin= g > fewer workers and preventing it? > > I don't think that we can possibly find a universal limit that will be > appropriate for all possible configurations. By now we are using a pretty > simple formula for parallel degree calculation. Since user have several > ways > to affect this formula, I guess that there will be no problems with it > (except > my concerns about opt-out style). > > > 4. Would it make sense to add a table level override to disable > parallelism or set parallel worker count? > > We already have the "autovacuum_parallel_workers" reloption that is used = as > an additional limit for the number of parallel workers. In particular, th= is > reloption can be used to disable parallelism at all. > > > > > I ran some perf tests to show the improvements with parallel vacuum and > shared below. > > Thank you very much! > > > Observations: > > > > 1. Parallel autovacuum provides consistent speedup. With cost_limit=3D2= 00 > and > > 7 workers, vacuum completes 1.41x faster (71s -> 50s). With > cost_limit=3D60, > > the speedup is 1.25x (194s -> 154s). > > 2. I see the benefit comes from parallelizing index vacuum. With 8 > indexes totaling > > ~530 MB, parallel workers scan indexes concurrently instead of the > leader > > scanning them one by one. The leader's CPU user time drops from ~3s = to > > ~0.8s as index work is offloaded > > > > 1.41 speedup with 7 parallel workers may not seem like a great win, but i= t > is > a whole time of autovacuum operation (not only index bulkdel/cleanup) wit= h > pretty small indexes. > > May I ask you to run the same test with a higher table's size (several > dozen > gigabytes)? I think the results will be more "expressive". > I ran it with a Billion rows in a table with 8 indexes. The improvement with 7 workers is 1.8x. Please note that there is a fixed overhead in other vacuum steps, for example heap scan. In the environments where cost-based delay is used (the default), benefits will be modest unless vacuum_cost_delay is set to sufficiently large value. *Hardware:* CPU: Intel Xeon Platinum 8573C, 1 socket =C3=97 8 cores = =C3=97 2 threads =3D 16 vCPUs RAM: 128 GB (131,900 MB) Swap: None *Workload Description* *Table Schema:* CREATE TABLE avtest ( id bigint PRIMARY KEY, col1 int, -- random()*1e9 col2 int, -- random()*1e9 col3 int, -- random()*1e9 col4 int, -- random()*1e9 col5 int, -- random()*1e9 col6 text, -- 'text_' || random()*1e6 (short text ~10 chars) col7 timestamp, -- now() - random()*365 days padding text -- repeat('x', 50) ) WITH (fillfactor =3D 90); *Indexes (8 total):* avtest_pkey =E2=80=94 btree on (id) bigint idx_av_col1 =E2=80=94 btree on (col1) int idx_av_col2 =E2=80=94 btree on (col2) int idx_av_col3 =E2=80=94 btree on (col3) int idx_av_col4 =E2=80=94 btree on (col4) int idx_av_col5 =E2=80=94 btree on (col5) int idx_av_col6 =E2=80=94 btree on (col6) text idx_av_col7 =E2=80=94 btree on (col7) timestamp Dead Tuple Generation: DELETE FROM avtest WHERE id % 5 IN (1, 2); This deletes exactly 40% of rows, uniformly distributed across all pages. Vacuum Trigger: Autovacuum is triggered naturally by lowering the threshold to 0 and setting scale_factor to a value that causes immediate launch after the DELETE. Worker Configurations Tested: 0 workers =E2=80=94 leader-only vacuum (baseline, no parallelism) 2 workers =E2=80=94 leader + 2 parallel workers (3 processes total) 4 workers =E2=80=94 leader + 4 parallel workers (5 processes total) 7 workers =E2=80=94 leader + 7 parallel workers (8 processes total, 1 pe= r index) Dataset: Rows: 1,000,000,000 Heap size: 139 GB Total size: 279 GB (heap + 8 indexes) Dead tuples: 400,000,000 (40%) Index Sizes: avtest_pkey 21 GB (bigint) idx_av_col7 21 GB (timestamp) idx_av_col1 18 GB (int) idx_av_col2 18 GB (int) idx_av_col3 18 GB (int) idx_av_col4 18 GB (int) idx_av_col5 18 GB (int) idx_av_col6 7 GB (text =E2=80=94 shorter keys, smaller index) Total indexes: 139 GB Server Settings: shared_buffers =3D 96GB maintenance_work_mem =3D 1GB max_wal_size =3D 100GB checkpoint_timeout =3D 1h autovacuum_vacuum_cost_delay =3D 0ms (NO throttling) autovacuum_vacuum_cost_limit =3D 1000 *Summary:* Workers Avg(s) Min(s) Max(s) Speedup Time Saved ------- ------ ------ ------ ------- ---------- 0 1645.93 1645.01 1646.84 1.00x =E2=80=94 2 1276.35 1275.64 1277.05 1.29x 369.58s (6.2 min) 4 1052.62 1048.92 1056.32 1.56x 593.31s (9.9 min) 7 892.23 886.59 897.86 1.84x 753.70s (12.6 min) Thanks, Satya --000000000000205d47064e46dbfb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Mon, Mar 30, 2= 026 at 1:44=E2=80=AFAM Daniil Davydov <3danissimo@gmail.com> wrote:
Hi,

On Mon, Mar 30, 2026 at 7:17=E2=80=AFAM SATYANARAYANA NARLAPURAM
<satyanar= lapuram@gmail.com> wrote:
>
> Thank you for working on this, very useful feature. Sharing a few thou= ghts:
>
> 1. Shouldn't we also cap by max_parallel_workers to avoid wasting = DSM resources in parallel_vacuum_compute_workers?

Actually, autovacuum_max_parallel_workers is already limited by
max_parallel_workers. It is not clear for me why we allow setting this GUC<= br> higher than max_parallel_workers, but if this happens, I think it is a user= 's
misconfiguration.

> 2. Is it intentional that other autovacuum workers not yield cost limi= ts to the parallel auto vacuum workers? Cost limits are distributed first e= qually to the autovacuum workers.
> and then they share that. Therefore, parallel workers will be heavily = throttled. IIUC, this problem doesn't exist with manual vacuum.
>=C2=A0 If we don't fix this, at least we should document this.

Parallel a/v workers inherit cost based parameters (including the
vacuum_cost_limit) from the leader worker. Do you mean that this can be too=
low value for parallel operation? If so, user can manually increase the
vacuum_cost_limit reloption for those tables, where parallel a/v sleeps too=
much (due to cost delay).

BTW, describing the cost limit propagation to the parallel a/v workers is worth mentioning in the documentation. I'll add it in the next patch ve= rsion.

> 3. Additionally, is there a point where, based on the cost limits, lau= nching additional workers becomes counterproductive compared to running few= er workers and preventing it?

I don't think that we can possibly find a universal limit that will be<= br> appropriate for all possible configurations. By now we are using a pretty simple formula for parallel degree calculation. Since user have several way= s
to affect this formula, I guess that there will be no problems with it (exc= ept
my concerns about opt-out style).

> 4. Would it make sense to add a table level override to disable parall= elism or set parallel worker count?

We already have the "autovacuum_parallel_workers" reloption that = is used as
an additional limit for the number of parallel workers. In particular, this=
reloption can be used to disable parallelism at all.

>
> I ran some perf tests to show the improvements with parallel vacuum an= d shared below.

Thank you very much!

> Observations:
>
> 1. Parallel autovacuum provides consistent speedup. With cost_limit=3D= 200 and
>=C2=A0 =C2=A0 7 workers, vacuum completes 1.41x faster (71s -> 50s).= With cost_limit=3D60,
>=C2=A0 =C2=A0 the speedup is 1.25x (194s -> 154s).
> 2. I see the benefit comes from parallelizing index vacuum. With 8 ind= exes totaling
>=C2=A0 =C2=A0 ~530 MB, parallel workers scan indexes concurrently inste= ad of the leader
>=C2=A0 =C2=A0 scanning them one by one. The leader's CPU user time = drops from ~3s to
>=C2=A0 =C2=A0 ~0.8s as index work is offloaded
>

1.41 speedup with 7 parallel workers may not seem like a great win, but it = is
a whole time of autovacuum operation (not only index bulkdel/cleanup) with<= br> pretty small indexes.

May I ask you to run the same test with a higher table's size (several = dozen
gigabytes)? I think the results will be more "expressive".

I ran it with a Billion rows in a table with = 8 indexes. The improvement with 7 workers is 1.8x.
Please note th= at there is a fixed overhead in other vacuum steps, for example heap scan.<= /div>
In the environments where cost-based delay=C2=A0is used (the defa= ult), benefits will be modest=C2=A0
unless vacuum_cost_delay=C2= =A0is set to sufficiently large value.

Hard= ware:
=C2=A0 CPU: =C2=A0 =C2=A0 Intel Xeon Platinum 8573C, 1 socket = =C3=97 8 cores =C3=97 2 threads =3D 16 vCPUs
=C2=A0 RAM: =C2=A0 =C2=A0 1= 28 GB (131,900 MB)
=C2=A0 Swap: =C2=A0 =C2=A0None

<= /b>
Workload Description

Table Schema:
=C2=A0 CREATE TABLE avtest (
=C2=A0 =C2=A0 =C2=A0 id =C2=A0 =C2=A0 = =C2=A0 bigint PRIMARY KEY,
=C2=A0 =C2=A0 =C2=A0 col1 =C2=A0 =C2=A0 int, = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- random()*1e9
=C2=A0 =C2=A0 =C2=A0 = col2 =C2=A0 =C2=A0 int, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- random()*1e9<= br>=C2=A0 =C2=A0 =C2=A0 col3 =C2=A0 =C2=A0 int, =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 -- random()*1e9
=C2=A0 =C2=A0 =C2=A0 col4 =C2=A0 =C2=A0 int, =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- random()*1e9
=C2=A0 =C2=A0 =C2=A0 col= 5 =C2=A0 =C2=A0 int, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- random()*1e9
= =C2=A0 =C2=A0 =C2=A0 col6 =C2=A0 =C2=A0 text, =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0-- 'text_' || random()*1e6 =C2=A0(short text ~10 chars)
= =C2=A0 =C2=A0 =C2=A0 col7 =C2=A0 =C2=A0 timestamp, =C2=A0 =C2=A0 -- now() -= random()*365 days
=C2=A0 =C2=A0 =C2=A0 padding =C2=A0text =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 -- repeat('x', 50)
=C2=A0 ) WITH (fillfact= or =3D 90);

Indexes (8 total):
=C2=A0 avtest_pkey =C2=A0 = =E2=80=94 btree on (id) =C2=A0 =C2=A0 =C2=A0 =C2=A0bigint
=C2=A0 idx_av_= col1 =C2=A0 =E2=80=94 btree on (col1) =C2=A0 =C2=A0 =C2=A0int
=C2=A0 idx= _av_col2 =C2=A0 =E2=80=94 btree on (col2) =C2=A0 =C2=A0 =C2=A0int
=C2=A0= idx_av_col3 =C2=A0 =E2=80=94 btree on (col3) =C2=A0 =C2=A0 =C2=A0int
= =C2=A0 idx_av_col4 =C2=A0 =E2=80=94 btree on (col4) =C2=A0 =C2=A0 =C2=A0int=
=C2=A0 idx_av_col5 =C2=A0 =E2=80=94 btree on (col5) =C2=A0 =C2=A0 =C2= =A0int
=C2=A0 idx_av_col6 =C2=A0 =E2=80=94 btree on (col6) =C2=A0 =C2=A0= =C2=A0text
=C2=A0 idx_av_col7 =C2=A0 =E2=80=94 btree on (col7) =C2=A0 = =C2=A0 =C2=A0timestamp

Dead Tuple Generation:
=C2=A0 DELETE FROM = avtest WHERE id % 5 IN (1, 2);
=C2=A0 This deletes exactly 40% of rows, = uniformly distributed across all pages.

Vacuum Trigger:
=C2=A0 Au= tovacuum is triggered naturally by lowering the threshold to 0 and setting<= br>=C2=A0 scale_factor to a value that causes immediate launch after the DE= LETE.

Worker Configurations Tested:
=C2=A0 0 workers =C2=A0=E2=80= =94 leader-only vacuum (baseline, no parallelism)
=C2=A0 2 workers =C2= =A0=E2=80=94 leader + 2 parallel workers (3 processes total)
=C2=A0 4 wo= rkers =C2=A0=E2=80=94 leader + 4 parallel workers (5 processes total)
= =C2=A0 7 workers =C2=A0=E2=80=94 leader + 7 parallel workers (8 processes t= otal, 1 per index)

Dataset:
=C2=A0 Rows: = =C2=A0 =C2=A0 =C2=A0 =C2=A0 1,000,000,000
=C2=A0 Heap size: =C2=A0 =C2= =A0139 GB
=C2=A0 Total size: =C2=A0 279 GB (heap + 8 indexes)
=C2=A0 = Dead tuples: =C2=A0400,000,000 (40%)

Index Sizes:
=C2=A0 avtest_p= key =C2=A0 =C2=A021 GB =C2=A0 (bigint)
=C2=A0 idx_av_col7 =C2=A0 =C2=A02= 1 GB =C2=A0 (timestamp)
=C2=A0 idx_av_col1 =C2=A0 =C2=A018 GB =C2=A0 (in= t)
=C2=A0 idx_av_col2 =C2=A0 =C2=A018 GB =C2=A0 (int)
=C2=A0 idx_av_c= ol3 =C2=A0 =C2=A018 GB =C2=A0 (int)
=C2=A0 idx_av_col4 =C2=A0 =C2=A018 G= B =C2=A0 (int)
=C2=A0 idx_av_col5 =C2=A0 =C2=A018 GB =C2=A0 (int)
=C2= =A0 idx_av_col6 =C2=A0 =C2=A0 7 GB =C2=A0 (text =E2=80=94 shorter keys, sma= ller index)
=C2=A0 Total indexes: 139 GB

Server Settings:
=C2= =A0 shared_buffers =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =3D 96GB
=C2=A0 maintenance_work_mem =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =3D 1GB
=C2=A0 max_wal_size =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=3D 100GB
=C2=A0 checkpoint_timeout =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D 1h
=C2=A0 autovacuum_vacuum_cost_delay = =C2=A0=3D 0ms (NO throttling)
=C2=A0 autovacuum_vacuum_cost_limit =C2=A0= =3D 1000


Summary:

Workers =C2=A0Avg(s) =C2=A0 =C2= =A0Min(s) =C2=A0 =C2=A0Max(s) =C2=A0 =C2=A0Speedup =C2=A0 Time Saved
---= ---- =C2=A0------ =C2=A0 =C2=A0------ =C2=A0 =C2=A0------ =C2=A0 =C2=A0----= --- =C2=A0 ----------
0 =C2=A0 =C2=A0 =C2=A0 =C2=A01645.93 =C2=A0 1645.0= 1 =C2=A0 1646.84 =C2=A0 =C2=A01.00x =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2= =80=94
2 =C2=A0 =C2=A0 =C2=A0 =C2=A01276.35 =C2=A0 1275.64 =C2=A0 1277.0= 5 =C2=A0 =C2=A01.29x =C2=A0 =C2=A0 369.58s (6.2 min)
4 =C2=A0 =C2=A0 =C2= =A0 =C2=A01052.62 =C2=A0 1048.92 =C2=A0 1056.32 =C2=A0 =C2=A01.56x =C2=A0 = =C2=A0 593.31s (9.9 min)
7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 892.23 =C2=A0 =C2= =A0886.59 =C2=A0 =C2=A0897.86 =C2=A0 =C2=A01.84x =C2=A0 =C2=A0 753.70s (12.= 6 min)


=C2=A0Thanks,
= Satya
--000000000000205d47064e46dbfb--