Re: crash-safe visibility map, take five

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: crash-safe visibility map, take five
Дата
Msg-id 18437.1305046811@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: crash-safe visibility map, take five  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: crash-safe visibility map, take five
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, May 10, 2011 at 11:34 AM, Jesper Krogh <jesper@krogh.cc> wrote:
>> Or what is the downside for keeping it across IO? Will it block other
>> processes trying to read it?

> Heikki might be in a better position to comment on that than I am,
> since he wrote the existing code.  But I think that's basically the
> issue.  When one process has an exclusive buffer lock, nobody else can
> scan the tuples in that block - so a sequential scan, for example,
> that reached that block, or an index scan that needed to probe into
> it, would pile up behind the read of the visibility map page.

Right, it's the loss of potential concurrency that's annoying here.

On the other hand, the concurrency loss might be entirely theoretical
--- in particular, if other potential readers of the heap page would
probably also need to wait for the visibility page to come in, then
nothing is gained by letting them acquire the heap page lock sooner.

I've not read this thread in any detail yet, but if we're going to be
jumping through extremely complex hoops to avoid that scenario, it might
be better to KISS ... especially in the first iteration.
        regards, tom lane


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

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: hint bit cache v5
Следующее
От: Robert Haas
Дата:
Сообщение: Re: collateral benefits of a crash-safe visibility map