Radim Marek <[email protected]> wrote: > Hi Shihao, thank you for the confirmation. I wasn't aware of the enhancements > series. > > It's definitely not a performance issue in the doc; rathe a resource limit. > Since 19 will go with this limitation I attached a small doc patch > about this. Hope I got the use of 'other' correctly based on current version > https://www.postgresql.org/docs/19/sql-repack.html
It's unfortunate that REPACK is probably the only command that exercises this combo CID limit. However, there can be other limits, e.g. REPACK being unable to catch up if the change rate is too high, excessive usage of disk for the decoded changes, etc. I think that the most important thing for the user to know is that the purpose of REPACK is to improve performance (via bloat removal and/or clustering), whereas "failsafe VACUUM" (i.e. VACUUM with INDEX_CLEANUP set to off) should be used to avoid the risk of XID wraparound. This kind of VACCUM is probably much faster and less likely to fail. I don't have a good idea about the wording right now. -- Antonin Houska Web: https://www.cybertec-postgresql.com
