Re: Relation extension scalability
От | Petr Jelinek |
---|---|
Тема | Re: Relation extension scalability |
Дата | |
Msg-id | 56F17D15.1050704@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: Relation extension scalability (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Relation extension scalability
|
Список | pgsql-hackers |
On 22/03/16 10:15, Dilip Kumar wrote: > > On Mon, Mar 21, 2016 at 8:10 PM, Amit Kapila <amit.kapila16@gmail.com > <mailto:amit.kapila16@gmail.com>> wrote: > 11. > +{ > +/* > +* First try to get the lock in no-wait mode, if succeed extend one > + > * block, else get the lock in normal mode and after we get the lock > -LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE); > +buffer = > RelationAddOneBlock(relation, otherBuffer, bistate); > > Won't this cause one extra block addition after backend extends the > relation for multiple blocks, what is the need of same? > > > This is the block for this backend, Extra extend for future request and > already added to FSM. I could have added this count along with extra > block in RelationAddExtraBlocks, But In that case I need to put some > extra If for saving one buffer for this bakend and then returning that > the specific buffer to caller, and In caller also need to distinguish > between who wants to add one block or who have got one block added in > along with extra block. > > I think this way code is simple.. That everybody comes down will add one > block for self use. and all other functionality and logic is above, i.e. > wether to take lock or not, whether to add extra blocks or not.. > > I also think the code simplicity makes this worth it. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: