Re: REPACK and naming
От | Álvaro Herrera |
---|---|
Тема | Re: REPACK and naming |
Дата | |
Msg-id | 202509191239.x2bxoygrluit@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: REPACK and naming (David Rowley <dgrowleyml@gmail.com>) |
Список | pgsql-hackers |
On 2025-Sep-19, David Rowley wrote: > On Fri, 19 Sept 2025 at 21:36, Álvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > > > 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. Sure -- the IOT is the "primary index", so what you are saying is, I think, the same as what I was saying. > > 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. Yes: I mean, I imagine that an implementation of REPACK tab ORDER BY col2 (on normal heap tables) when there's no index on col2 would just use a seqscan-and-sort to put the tably in that physical order, and potentially store somewhere that "col2" is the order that was used. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Selbst das größte Genie würde nicht weit kommen, wenn es alles seinem eigenen Innern verdanken wollte." (Johann Wolfgang von Goethe) Ni aún el genio más grande llegaría muy lejos si quisiera sacarlo todo de su propio interior.
В списке pgsql-hackers по дате отправления: