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 |
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 |