Re: [PROPOSAL] Use SnapshotAny in get_actual_variable_range
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Dmitriy Sarafannikov <dsarafannikov@yandex.ru>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Borodin Vladimir <root@simply.name>, Хомик Кирилл <khomikki@yandex-team.ru>
Date: 2017-04-28T16:12:08Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Apr 27, 2017 at 5:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> How so? Shouldn't the indexscan go back and mark such tuples dead in >> the index, such that they'd be visited this way only once? If that's >> not happening, maybe we should try to fix it. > Hmm. Actually, I think the scenario I saw was where there was a large > number of tuples at the end of the index that weren't dead yet due to > an old snapshot held open. That index was being scanned by lots of > short-running queries. Those queries executed just fine, but they > took a long to plan because they had to step over all of the dead > tuples in the index one by one. But that was the scenario that we intended to fix by changing to SnapshotDirty, no? Or I guess not quite, because dead-but-still-visible-to-somebody tuples are rejected by SnapshotDirty. Maybe we need another type of snapshot that would accept any non-vacuumable tuple. I really don't want SnapshotAny semantics here, but a tuple that was live more recently than the xmin horizon seems like it's acceptable enough. HeapTupleSatisfiesVacuum already implements the right behavior, but we don't have a Snapshot-style interface for it. regards, tom lane
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