Re: pg_stat_progress_create_index vs. parallel index builds

From: Greg Nancarrow <gregn4422(at)gmail(dot)com>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_stat_progress_create_index vs. parallel index builds
Date: 2021-06-04 07:25:53
Message-ID: CAJcOf-dGDNz8D7jupjk4YiY190caqw7dAiuuAr5E4kQodJ9KVw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 3, 2021 at 1:49 AM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
>
> On Wed, 2 Jun 2021 at 17:42, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2021-06-04 07:38:38 Re: Skip partition tuple routing with constant partition key
Previous Message Michael Paquier 2021-06-04 07:24:02 Re: fdatasync performance problem with large number of DB files