Re: [PROPOSAL] Use SnapshotAny in get_actual_variable_range

From: Dmitriy Sarafannikov <dsarafannikov(at)yandex(dot)ru>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, "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
Date: 2017-05-02 08:59:30
Message-ID: 7E4A7933-9921-47E0-BF45-DFB55747A858@yandex.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> If that is the case, then how would using SnapshotAny solve this
> problem. We get the value from index first and then check its
> visibility in heap, so if time is spent in _bt_checkkeys, why would
> using a different kind of Snapshot solve the problem?

1st scanning on the index with SnapshotAny will accept this rows and
will not mark this entries as killed.

Theremore, killed entries are ignored on standby. And scanning with
SnapshotAny will always accept first row from index.
/*
* During recovery we ignore killed tuples and don't bother to kill them
* either. We do this because the xmin on the primary node could easily be
* later than the xmin on the standby node, so that what the primary
* thinks is killed is supposed to be visible on standby. So for correct
* MVCC for queries during recovery we must ignore these hints and check
* all tuples. Do *not* set ignore_killed_tuples to true when running in a
* transaction that was started during recovery. xactStartedInRecovery
* should not be altered by index AMs.
*/
scan->kill_prior_tuple = false;
scan->xactStartedInRecovery = TransactionStartedDuringRecovery();
scan->ignore_killed_tuples = !scan->xactStartedInRecovery;

We execute this read-only queries on standby.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mahi Gurram 2017-05-02 09:12:15 Regarding B-Tree Lookup
Previous Message Beena Emerson 2017-05-02 08:47:36 Re: multi-column range partition constraint