| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Dmitriy Sarafannikov <dsarafannikov(at)yandex(dot)ru>, "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-27 21:22:25 |
| Message-ID: | 17340.1493328145@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Apr 27, 2017 at 4:08 AM, Dmitriy Sarafannikov
> <dsarafannikov(at)yandex(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2017-04-27 21:27:38 | Re: [PROPOSAL] Use SnapshotAny in get_actual_variable_range |
| Previous Message | Tom Lane | 2017-04-27 21:06:24 | Re: Unportable implementation of background worker start |