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: PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
Andrey Borodin <amborodin86@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>
Date: 2024-09-08T15:18:00Z
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
- create_index_concurrently_with_aux_index_or_rotated_snapshots.patch (text/x-patch) patch
Hello, Matthias! >> - I notice you've added a new argument to >> heapam_index_build_range_scan. I think this could just as well be >> implemented by reading the indexInfo->ii_Concurrent field, as the >> values should be equivalent, right? > Not always; currently, it is set by ResetSnapshotsAllowed[5]. > We fall back to regular index build if there is a predicate or expression in the index (which should be considered "safe" according to [6]). > However, we may remove this check later. > Additionally, there is no sense in resetting the snapshot if we already have an xmin assigned to the backend for some reason. I realized you were right. It's always possible to reset snapshots for concurrent index building without any limitations related to predicates or expressions. Additionally, the PROC_IN_SAFE_IC flag is no longer necessary since snapshots are rotating quickly, and it's possible to wait for them without requiring any special exceptions for CREATE/REINDEX INDEX CONCURRENTLY. Currently, it looks like this [1]. I've also attached a single large patch just for the case. I plan to restructure the patch into the following set: * Introduce catalogXmin as a separate value to calculate the horizon for the catalog. * Add the STIR access method. * Modify concurrent build/reindex to use an aux-index approach without snapshot rotation. * Add support for snapshot rotation for non-parallel and non-unique cases. * Extend support for snapshot rotation in parallel index builds. * Implement snapshot rotation support for unique indexes. Best regards, Mikhail [1]: https://github.com/postgres/postgres/compare/master...michail-nikolaev:postgres:new_index_concurrently_approach_rebased?expand=1 >