| From: | Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com> |
|---|---|
| To: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andrey Borodin <amborodin86(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Subject: | Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements |
| Date: | 2025-01-08 02:12:00 |
| Message-ID: | CANtu0ogGSjUBuuyjMX3bhNThMGQwOhBTKdMHVNY4O8JjH47-_A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hello, everyone!
Some updates:
* Rebased.
* Resolved the issue with integer overflow in memory calculation, which
caused a performance drop during sorting.
* Fixed a broken tag in the documentation.
* Added per-tuple progress tracking in the validation phase.
Additionally, the anomaly with the GIST index has been clarified.
It occurs because the first phase is slow, and many tuples need to be
inserted during the validation phase.
For each tuple, heapam_index_fetch_tuple is called, even for those on the
same page.
It might be possible to implement a batched version of
heapam_index_fetch_tuple to handle multiple tuples on the same page and
mitigate this issue.
Best regards,
Mikhail.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2025-01-08 02:14:25 | Re: Psql meta-command conninfo+ |
| Previous Message | Andres Freund | 2025-01-08 02:10:50 | Reorder shutdown sequence, to flush pgstats later |