Question: why do reindex? #17
Comments
|
vacuum full rewrite table and all indexes, but vacuum full uses exclusive lock - and this is primary reason to using pgcompacttable or pg_repack. But pgcompactable does not use vacuum full (and no reindex command too), instead it calls updates on table and rebuild indexes by creating new index (concurrently), rename new index to old one and then drop old index. So reindex in pgcompacttable is another stuff and has few options to control behavior. |
|
I understand about vacuum full and exclusive lock, and I also understand pgcompacttable is basically a vacuum full without the long locks. My question is why have REINDEX parameters for pgcompacttable since you are basically dropping indexes and creating new ones? |
|
which parameters do you mean? beside creating and dropping indexes (which could be done concurrently without heavy locks) pgcompacttable also renaming newly created indexes to old name which requires short heavy lock which might not be available at a time and pgcompacttable will try to acquire it cycle with lock timeout and pause between iterations. so that's why reindex-retry-count, reindex-retry-pause, reindex-lock-timeout were introduced. |
|
I'm sorry but I am still not understanding you completely. When you say REINDEX, you don't mean the actual PostgreSQL REINDEX command, you mean rename command, right? |
|
Yes, we speaking not about reindex command (it uses heavy lock too). pgcompacttable uses word "reindex" for process create index concurrently + alter index rename + drop index concurrently. |
Uh oh!
There was an error while loading. Please reload this page.
A full vacuum does a rewrite of all the table and indexes, so why have REINDEX options?
btw, I love your verbose output!
The text was updated successfully, but these errors were encountered: