I'm looking for an alternative to executing the CLUSTER command on large tables to keep data efficiently organized on disk, since it requires an ACCESS EXCLUSIVE lock on tables being clustered, making them unavailable for a considerable amount of time.
After reading about covering indexes I got the idea of creating a btree multi-column index specifying all of my table columns, and not just those relevant for the query condition.
The benefits, I suppose, would be twofold:
- The query plan would be optimized due to the condition relevant columns being specified first on the index, according to the query's expected data fetch pattern.
- All remaining columns would also be included in the index, meaning this index would be a copy of the table and already organized efficiently on disk due to the btree structure.
I believe queries over this index would be very efficient and since it is covering the whole table wouldn't need to access table data scattered on disk.
Would like to ask if this a reasonable solution, and what are the potential downsides to this approach? (besides the additional storage space required for the covering index and expected - small? - decrease in insert/update/delete performance)