Re: sequence indexes
От | Hannu Krosing |
---|---|
Тема | Re: sequence indexes |
Дата | |
Msg-id | 3C56A0DF.6380290A@tm.ee обсуждение исходный текст |
Ответ на | Re: sequence indexes (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
mlw wrote: > > Hannu Krosing wrote: > > > > mlw wrote: > > > > > > > > > Could one run a postgresql process in a lower priority process and > > > perform lazy vacuums without affecting performance all that much? > > > > One must be very careful not to introduce reverse priority problems - > > i.e. a > > lower priority process locking some resource and then not letting go > > while > > higher priority processes are blocked from running due to needing that > > lock. > I understand that, hmm. I wonder if the lock code could boost the priority of a > process which owns a lock. > > > > > In my tests 1 vacuum process slowed down 100 concurrent pgbench > > processes > > by ~2 times. > > Is that good or bad? I had hoped it to take somewhat proportional time, i.e. slow other backends down by 1/100. > > > A live index compaction can be done by indexing the table with a > > > temporary name rename the old index, rename the new index to the old > > > name, and drop the old index. > > > > Isn't this what REINDEX command does ? > > REINDEX can't be run on a live system, can it? It will probably lock something, but otherways I don't say why it can't. You may have to add FORCE to the end of command thus: reindex table tablename force; ------------- Hannu
В списке pgsql-hackers по дате отправления: