Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags
Дата
Msg-id CAB7nPqR79zJGajqx_u1U9HWx-nzyY8ffCWRPVv9VyiNqab97XQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Ответы Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags  ("Seki, Eiji" <seki.eiji@jp.fujitsu.com>)
Список pgsql-hackers
On Thu, Feb 16, 2017 at 10:48 AM, Haribabu Kommi
<kommi.haribabu@gmail.com> wrote:
> Because of the above reason, we need a new API or some change in API
> to provide the Oldest xmin by ignoring the ANALYZE transactions, so that
> it will reduce the size of WOS and improves the VCI query performance.

A new API in core is not completely mandatory either. As mentioned
during last week developer meeting to Seki-san, as the list of PGXACT
and PGPROC is in shared memory you could as well develop your own
version. Still there is a limitation with
KnownAssignedXidsGetOldestXmin in recovery, which may be better if
exposed at quick glance but you actually don't care for storage,
right? If the change makes sense, it seems to me that making a routine
more extensible makes the most sense in this case if the API extension
can be used by modules with more goals in mind.
-- 
Michael



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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] WIP: [[Parallel] Shared] Hash