On Fri, 19 Sept 2025 at 21:36, Álvaro Herrera <[email protected]> wrote: > > On 2025-Sep-19, David Rowley wrote: > > > I was just thinking about how much of a heap-ism cluster using an > > index is. If we were to ever have an index organised table AM, what > > would it mean to REPACK tab USING INDEX idx? Would that "secondary" > > index then go away and the table would become that index? or would > > both continue to exist and the secondary index would be surplus? > > So, there's already an implementation of an index-organized table in > OrioleDB, as I understand, so maybe we can ask Alexander K. about this. > I suspect it's fine to say that if you have a table for which it makes > no sense to use REPACK USING INDEX, then we just throw an error in that > case (but I suppose plain REPACK continues to work, and it just > recreates/compacts the primary index and rebuilds all secondary indexes, > just like VACUUM FULL would presumably do.)
What I was wondering was if REPACK tab ORDER BY col; would be the way to change the IOT's order. Otherwise, I'm not sure how you'd make that work aside from providing something like: SELECT pg_recluster_iot_by(....) > > table_relation_copy_for_cluster() does support both use > > of an Index to get presorted results and sorting by the index's key > > columns, so it doesn't seem impossible that the ability to cluster a > > table *specifically* by an index couldn't easily go away at some > > point. > > Well, I hope you mean that clustering by an index would stop being the > _only_ way, not that it would completely disappear as an option. I mean support clustered orders that don't exist in any defined index. David
