Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range
Дата
Msg-id 6719.1493476491@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range  (Dmitriy Sarafannikov <dsarafannikov@yandex.ru>)
Ответы Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range
Список pgsql-hackers
Dmitriy Sarafannikov <dsarafannikov@yandex.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dmitriy Sarafannikov
Дата:
Сообщение: Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: [HACKERS] convert EXSITS to inner join gotcha and bug