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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range
Дата
Msg-id 17340.1493328145@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range  (Andres Freund <andres@anarazel.de>)
Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range  (Vladimir Borodin <root@simply.name>)
Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Apr 27, 2017 at 4:08 AM, Dmitriy Sarafannikov
> <dsarafannikov@yandex.ru> wrote:
>> I'd like to propose to search min and max value in index with SnapshotAny in
>> get_actual_variable_range function.

> +1 from me, but Tom rejected that approach last time.

I remain concerned about the fact that this would allow accepting deleted
values that might be way outside the surviving range of values.
SnapshotDirty is a bit lax about tuple state, but it's not so lax as to
accept fully dead tuples.

>> But if we delete many rows from beginning or end of index, it would be
>> very expensive too because we will fetch each dead row and reject it.

> Yep, and I've seen that turn into a serious problem in production.

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.
        regards, tom lane



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Unportable implementation of background worker start
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] [PROPOSAL] Use SnapshotAny in get_actual_variable_range