Re: [PROPOSAL] Use SnapshotAny in get_actual_variable_range

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dmitriy Sarafannikov <dsarafannikov(at)yandex(dot)ru>
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 14:34:51
Message-ID: 6719.1493476491@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dmitriy Sarafannikov <dsarafannikov(at)yandex(dot)ru> writes:
>> Maybe we need another type of snapshot that would accept any
>> non-vacuumable tuple. I really don't want SnapshotAny semantics here,

> 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?

Right. You haven't shown us much about the use-case you're concerned
with, so it's not clear what's actually needed.

> And what about don’t fetch actual min and max values from indexes
> whose columns doesn’t involved in join?

We don't fetch that info unless we need it.

I'm not entirely certain, but there could be cases where a single
planning cycle ends up fetching that data more than once. (There's
caching at the RestrictInfo level, but that might not be enough.)
So a line of thought that might be worth looking into is adding a
lower layer of caching to make sure it's not done more than once per
plan. Again, whether this saves anything would depend a lot on
specific use-cases.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2017-04-29 17:35:05 Re: convert EXSITS to inner join gotcha and bug
Previous Message Dmitriy Sarafannikov 2017-04-29 08:15:25 Re: [PROPOSAL] Use SnapshotAny in get_actual_variable_range