| 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 13:12:37 |
| Message-ID: | CAJcOf-dSZAjnvjQUjniEa+aA7k6ed-fOmafjvaQd5Djw1NN3Ow@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jun 4, 2021 at 5:25 PM Greg Nancarrow <gregn4422(at)gmail(dot)com> wrote:
>
> 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.
>
Seems to be because in the serial case, the sort occurs after the scan
is complete (obviously) but in the parallel case, the scan and sort
are combined, so (after patch application) a portion of the then
reported "sorting live tuples" phase is actually "scanning table".
Regards,
Greg Nancarrow
Fujitsu Australia
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joel Jacobson | 2021-06-04 13:18:03 | Re: security_definer_search_path GUC |
| Previous Message | Fabien COELHO | 2021-06-04 13:03:36 | Re: Failures with gcd functions with GCC snapshots GCC and -O3 (?) |