Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags
Date
Msg-id CAB7nPqR79zJGajqx_u1U9HWx-nzyY8ffCWRPVv9VyiNqab97XQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Responses Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags  ("Seki, Eiji" <seki.eiji@jp.fujitsu.com>)
List 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 by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] WIP: [[Parallel] Shared] Hash