Re: [PROPOSAL] Use SnapshotAny in get_actual_variable_range

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-28 15:31:11
Message-ID: CA+TgmobTd_eUqKWfGHPcBb2k53mpLzB7UaBzdO-BC0q0ds91LA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 27, 2017 at 5:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> 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.

Hmm. Actually, I think the scenario I saw was where there was a large
number of tuples at the end of the index that weren't dead yet due to
an old snapshot held open. That index was being scanned by lots of
short-running queries. Those queries executed just fine, but they
took a long to plan because they had to step over all of the dead
tuples in the index one by one. That increased planning time -
multiplied by the number of times it was incurred - was sufficient to
cripple the system.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2017-04-28 15:56:34 Re: convert EXSITS to inner join gotcha and bug
Previous Message Teodor Sigaev 2017-04-28 14:42:08 Re: convert EXSITS to inner join gotcha and bug