Re: Relation extension scalability

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Relation extension scalability
Дата
Msg-id 28823.1427659669@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Relation extension scalability  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Relation extension scalability  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2015-03-29 15:21:44 -0400, Tom Lane wrote:
>> One idea that might help is to change smgrextend's API so that it doesn't
>> need a buffer to write from, but just has an API of "add a prezeroed block
>> on-disk and tell me the number of the block you added".  On the other
>> hand, that would then require reading in the block after allocating a
>> buffer to hold it (I don't think you can safely assume otherwise) so the
>> added read step might eat any savings.

> Yea, I was thinking that as well. We simply could skip the reading step
> by setting up the contents in the buffer manager without a read in this
> case...

No, you can't, at least not if the point is to not be holding any
exclusive lock by the time you go to talk to the buffer manager.  There
will be nothing stopping some other backend from writing into that page of
the file before you can get hold of it.  If the buffer they used to do the
write has itself gotten recycled, there is nothing left at all to tell you
your page image is out of date.
        regards, tom lane



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Relation extension scalability
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Relation extension scalability