Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags

From: "Seki, Eiji" <seki(dot)eiji(at)jp(dot)fujitsu(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags
Date: 2017-02-14 06:19:10
Message-ID: A11BD0E1A40FAC479D740CEFA373E203396A4D3F@g01jpexmbkw05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

I propose the patch that adds a function GetOldestXminExtended that is like GetOldestXmin but can ignore arbitrary vacuum flags. And then, rewrite GetOldestXmin to use it. Note that this is done so as not to change the behavior of GetOldestXmin.

This change will be useful for features that only reads rows that are visible by all transactions and could not wait specific processes (VACUUM, ANALYZE, etc...) for performance. Our company (Fujitsu) is developing such an extension. In our benchmark, we found that waiting an ANALYZE process created by autovacuum daemon often has a significant impact to the performance although the waited process do only reading as to the table. So I hope to ignore it using GetOldestXminExtend as below. The second argument represents flags to ignore.

GetOldestXminExtended(rel, PROC_IN_VACUUM | PROC_IN_LOGICAL_DECODING | PROC_IN_ANALYZE);

Note: We can ignore VACUUM processes or VACUUM with ANALYZE processes using the second option of GetOldesXmin, "ignoreVacuum". However, we cannot ignore only ANALYZE processes because the "ignoreVacuum" = true is same to the following.

GetOldestXminExtended(rel, PROC_IN_VACUUM | PROC_IN_LOGICAL_DECODING)

This change should have no impact to the existing GetOldestXmin without slight overhead to call the function.

I'm not sure that this feature is useful in general.
Please let me know your opinion if you are interested.

Regards,
Eiji Seki
Fujitsu.

Attachment Content-Type Size
get_oldest_xmin_extended.patch application/octet-stream 1.7 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-02-14 06:30:47 Re: contrib modules and relkind check
Previous Message Amit Langote 2017-02-14 06:18:27 Re: contrib modules and relkind check