| From: | Dmitriy Sarafannikov <dsarafannikov(at)yandex(dot)ru> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | 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-04-29 08:15:25 |
| Message-ID: | E3474B24-6CCD-47BB-9AF3-1E6017B26793@yandex.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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.
If I understood correctly, this new type of snapshot would help if
there are long running transactions which can see this tuples.
But if there are not long running transactions, it will be the same.
Am i right?
And what about don’t fetch actual min and max values from indexes
whose columns doesn’t involved in join?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-04-29 14:34:51 | Re: [PROPOSAL] Use SnapshotAny in get_actual_variable_range |
| Previous Message | Noah Misch | 2017-04-29 04:33:49 | Re: some review comments on logical rep code |