|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Dmitriy Sarafannikov <dsarafannikov(at)yandex(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Borodin Vladimir <root(at)simply(dot)name>, Хомик Кирилл <khomikki(at)yandex-team(dot)ru>|
|Subject:||Re: [PROPOSAL] Use SnapshotAny in get_actual_variable_range|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Apr 27, 2017 at 5:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
|Next Message||Robert Haas||2017-04-28 16:25:04||Re: Declarative partitioning - another take|
|Previous Message||Tom Lane||2017-04-28 15:59:45||Re: convert EXSITS to inner join gotcha and bug|