On 2026-May-13, Chao Li wrote: > After some investigation, I think I see the mismatch: > > * get_relation_info(): non-ordered GiST cannot provide sort order. > That is expected. > * copy_table_data() only uses plan_cluster_use_sort() for btree. For > any other clusterable index, it sets use_sort = false and does a raw > index scan. > * The docs say REPACK can re-sort using index scan “if the index is a > b-tree” or seqscan+sort, which does not describe what the code > actually does for GiST. > > I am not sure whether we should change the behavior in PG19. Alvaro > may have a better idea about that. But I agree that we can at least > clarify the code comment and documentation. The attached patch > attempts to do that.
I am sure that we should not change the behavior for 19. We could change it in 20, perhaps. But I think the really gross problem is that somehow I made the documentation say exactly the opposite of truth, in the rework for commit ac58465e0618. I fixed that just now with by pushing 07aef52eba3c, which includes your (Chao's) proposed change; but also, while reading and rereading the existing docs and your patch, it struck me that the preexisting text was not super nice either: there was one introductory text, then some technical details, then some more discussion, then more technicalities. That was weird and probably just historical accident. I reordered the text and made some other wording changes. I *think* result is reasonable, or at least it contains no egregious errors; but maybe it could be further improved, if anybody is interested. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "El Maquinismo fue proscrito so pena de cosquilleo hasta la muerte" (Ijon Tichy en Viajes, Stanislaw Lem)
