Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements

Mihail Nikalayeu <michail.nikolaev@gmail.com>

From: Michail Nikolaev <michail.nikolaev@gmail.com>

To: Matthias van de Meent <boekewurm+postgres@gmail.com>

Cc: Melanie Plageman <melanieplageman@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Andrey Borodin <amborodin86@gmail.com>

Date: 2024-05-07T12:35:13Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Revert changes to CONCURRENTLY that "sped up" Xmin advance
- e28bb8851969 15.0 cited
VACUUM: ignore indexing operations with CONCURRENTLY
- d9d076222f5b 14.0 cited
Avoid spurious waits in concurrent indexing
- c98763bf51bf 14.0 cited

Attachments

v2-0001-WIP-fix-d9d076222f5b-VACUUM-ignore-indexing-opera.patch (text/x-patch) patch v2-0001

Hello, Matthias and others!

Updated WIP in attach.

Changes are:
* Renaming, now it feels better for me
* More reliable approach in `GlobalVisHorizonKindForRel` to make sure we
have not missed `rd_safeindexconcurrentlybuilding` by calling
`RelationGetIndexList` if required
* Optimization to avoid any additional `RelationGetIndexList` if zero of
concurrently indexes are being built
* TOAST moved to TODO, since looks like it is out of scope - but not sure
yet, need to dive dipper

TODO:
* TOAST
* docs and comments
* make sure non-data tables are not affected
* Per-database scope of optimization
* Handle index building errors correctly in optimization code
* More tests: create index, multiple re-indexes, multiple tables

Thanks,
Michail.