vacuum freeze - possible improvements

Поиск
Список
Период
Сортировка
От Virender Singla
Тема vacuum freeze - possible improvements
Дата
Msg-id CAM6Zo8y-fuCu+3zf42=JcMtN5xU5hQqbYXAii-QKU8U4oAmVJw@mail.gmail.com
обсуждение исходный текст
Ответы Re: vacuum freeze - possible improvements
Список pgsql-hackers
Hi Postgres Community,

Regarding anti wraparound vacuums (to freeze tuples), I see it has to scan all the pages which are not frozen-all (looking at visibility map). That means even if we want to freeze less transactions only (For ex - by increasing parameter vacuum_freeze_min_age to 1B), still it will scan all the pages in the visibility map and a time taking process.

Can there be any improvement on this process so VACUUM knows the tuple/pages of those transactions which need to freeze up.

Benefit of such an improvement is that if we are reaching transaction id close to 2B (and downtime), that time we can quickly recover the database with vacuuming freeze only a few millions rows with quick lookup rather than going all the pages from visibility map.

For Ex - A Binary Tree structure where it gets all the rows corresponding to a table including transaction ids. So whenever we say free all tuples having transaction id greater than x and less than y. Yes that makes extra overhead on data load and lots of other things to consider.


Thanks,
Virender





В списке pgsql-hackers по дате отправления:

Предыдущее
От: Christoph Berg
Дата:
Сообщение: Re: pgsql: Move tablespace path re-creation from the makefiles to pg_regres
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: Problems around compute_query_id