Re: [PROPOSAL] Use SnapshotAny in get_actual_variable_range
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Dmitriy Sarafannikov <dsarafannikov@yandex.ru>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Borodin Vladimir <root@simply.name>, Хомик Кирилл <khomikki@yandex-team.ru>
Date: 2017-05-08T13:47:04Z
Lists: pgsql-hackers
On Mon, May 8, 2017 at 6:30 PM, Dmitriy Sarafannikov <dsarafannikov@yandex.ru> wrote: > > I think we can use RecentGlobalDataXmin for non-catalog relations and > RecentGlobalXmin for catalog relations (probably a check similar to > what we have in heap_page_prune_opt). > > > I took check from heap_page_prune_opt (Maybe this check must be present as > separate function?) > But it requires to initialize snapshot for specific relation. > + else \ + (snapshotdata).xmin = \ + TransactionIdLimitedForOldSnapshots(RecentGlobalDataXmin, \ + relation); \ I think we don't need to use TransactionIdLimitedForOldSnapshots() as that is required to override xmin for table vacuum/pruning purposes. > Maybe we need > to use GetOldestXmin()? It is a costly call as it needs ProcArrayLock, so I don't think it makes sense to use it here. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Improve performance of get_actual_variable_range with recently-dead tuples.
- 3ca930fc39cc 11.0 landed
-
Use SnapshotDirty rather than an active snapshot to probe index endpoints.
- fccebe421d0c 9.4.0 cited