[HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags
От | Seki, Eiji |
---|---|
Тема | [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitrary vacuum flags |
Дата | |
Msg-id | A11BD0E1A40FAC479D740CEFA373E203396A4D3F@g01jpexmbkw05 обсуждение исходный текст |
Ответы |
Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags
Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags Re: [HACKERS] Proposal: GetOldestXminExtend for ignoring arbitraryvacuum flags |
Список | pgsql-hackers |
Hi all, I propose the patch that adds a function GetOldestXminExtended that is like GetOldestXmin but can ignore arbitrary vacuumflags. 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 specificprocesses (VACUUM, ANALYZE, etc...) for performance. Our company (Fujitsu) is developing such an extension. In ourbenchmark, we found that waiting an ANALYZE process created by autovacuum daemon often has a significant impact to theperformance although the waited process do only reading as to the table. So I hope to ignore it using GetOldestXminExtendas 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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: