Re: Relation extension scalability - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Relation extension scalability
Date
Msg-id CAA4eK1J_U+DD+i-AA9v9xOeZww7ud7-szJ_t7KZcQVFhXd6UgQ@mail.gmail.com
Whole thread Raw
In response to Re: Relation extension scalability  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Relation extension scalability
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: WIP: Access method extendability
Next
From: Peter Geoghegan
Date:
Subject: Re: Using quicksort for every external sort run