Re: REPACK and naming

On Fri, 19 Sept 2025 at 21:36, Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> 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