Re: Relation extension scalability

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Relation extension scalability
Дата
Msg-id CAA4eK1J_U+DD+i-AA9v9xOeZww7ud7-szJ_t7KZcQVFhXd6UgQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Relation extension scalability  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Relation extension scalability  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, Mar 24, 2016 at 12:09 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Mar 22, 2016 at 1:12 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:
>
> I've read this over several times and looked at
> RecordAndGetPageWithFreeSpace() and I'm still confused.  First of all,
> if the lock was acquired by some other backend which did
> RelationAddExtraBlocks(), it *will* have updated the FSM - that's the
> whole point.
>

It doesn't update the FSM uptill root in some cases, as per comments on top of RecordPageWithFreeSpace and the code as well.
 
>
>   Second, if the other backend extended the relation in
> some other manner and did not extend the FSM, how does calling
> RecordAndGetPageWithFreeSpace help?  As far as I can see,
> GetPageWithFreeSpace and RecordAndGetPageWithFreeSpace are both just
> searching the FSM, so if one is stymied the other will be too.  What
> am I missing?
>

RecordAndGetPageWithFreeSpace() tries to search from the oldPage passed to it, rather than from top, so even if  RecordPageWithFreeSpace() doesn't update till root, it will be able to search the newly added page.  I agree with whatever you have said in another mail that we should introduce a new API to do a more targeted search for such cases.


With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: WIP: Access method extendability
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Using quicksort for every external sort run