Re: why there is not VACUUM FULL CONCURRENTLY?
От | Antonin Houska |
---|---|
Тема | Re: why there is not VACUUM FULL CONCURRENTLY? |
Дата | |
Msg-id | 49792.1741027227@localhost обсуждение исходный текст |
Ответ на | Re: why there is not VACUUM FULL CONCURRENTLY? (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Список | pgsql-hackers |
Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > On 2025-Feb-26, Antonin Houska wrote: > > > @@ -403,39 +381,38 @@ cluster_rel(Relation OldHeap, Oid indexOid, ClusterParams *params) > > * would work in most respects, but the index would only get marked as > > * indisclustered in the current database, leading to unexpected behavior > > * if CLUSTER were later invoked in another database. > > + * > > + * REPACK does not set indisclustered. XXX Not sure I understand the > > + * comment above: how can an attribute be set "only in the current > > + * database"? > > */ > > Regarding this XXX comment, what's going on here is this: a CLUSTER > command needs to remember the index that a table is clustered on. We > keep track of this in pg_index.indisclustered. But pg_index is a local > relation, not shared across databases -- so the current CLUSTER command > can effect the update on the current database's pg_index only, not on > other databases. So if the user were to run CLUSTER on one database > specifying an index, then connect to another one and expect CLUSTER > without specifying an index to honor the previously specified index, > that would not work. Naturally this is only a problem for shared > catalogs. Not being able to handle this for shared catalogs is not a > big loss. Thanks for explanation. The reason I failed to understand this was probably that I tried to imagine something worse. -- Antonin Houska Web: https://www.cybertec-postgresql.com
В списке pgsql-hackers по дате отправления: