Re: pg_stat_progress_create_index vs. parallel index builds - Mailing list pgsql-hackers

From Greg Nancarrow
Subject Re: pg_stat_progress_create_index vs. parallel index builds
Date
Msg-id CAJcOf-dGDNz8D7jupjk4YiY190caqw7dAiuuAr5E4kQodJ9KVw@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_progress_create_index vs. parallel index builds  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: pg_stat_progress_create_index vs. parallel index builds
Re: pg_stat_progress_create_index vs. parallel index builds
Re: pg_stat_progress_create_index vs. parallel index builds
List pgsql-hackers
On Thu, Jun 3, 2021 at 1:49 AM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
>
> On Wed, 2 Jun 2021 at 17:42, Tomas Vondra <tomas.vondra@enterprisedb.com> wrote:
> >
> > Nice. I gave it a try on the database I'm experimenting with, and it
> > seems to be working fine. Please add it to the next CF.
>
> Thanks, cf available here: https://commitfest.postgresql.org/33/3149/
>

The patch looks OK to me. It seems apparent that the lines added by
the patch are missing from the current source in the parallel case.

I tested with and without the patch, using the latest PG14 source as
of today, and can confirm that without the patch applied, the "sorting
live tuples" phase is not reported in the parallel-case, but with the
patch applied it then does get reported in that case. I also confirmed
that, as you said, the patch only addresses the usual case where the
parallel leader participates in the parallel operation.
What is slightly puzzling to me (and perhaps digging deeper will
reveal it) is why this "sorting live tuples" phase seems so short in
the serial case compared to the parallel case?
For example, in my test I created an index on a column of a table
having 10 million records, and it took about 40 seconds, during which
the "sorting live tuples" phase seemed to take about 8 seconds. Yet
for the serial case, index creation took about 75 seconds, during
which the "sorting live tuples" phase seemed to take about 1 second.

Regards,
Greg Nancarrow
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Duplicate history file?
Next
From: Amit Langote
Date:
Subject: Re: Skip partition tuple routing with constant partition key