Re: Relation extension scalability
От | Jim Nasby |
---|---|
Тема | Re: Relation extension scalability |
Дата | |
Msg-id | 56E35C43.5030604@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Relation extension scalability (Petr Jelinek <petr@2ndquadrant.com>) |
Ответы |
Re: Relation extension scalability
Re: Relation extension scalability |
Список | pgsql-hackers |
On 3/11/16 5:14 PM, Petr Jelinek wrote: >> I don't really understand this part about concurrent DDL. If there >> were concurrent DDL going on, presumably other backends would be >> blocked on the relation lock, not the relation extension lock - and it >> doesn't seem likely that you'd often have a huge pile-up of inserters >> waiting on concurrent DDL. But I guess it could happen. >> > > Yeah I was thinking about the latter part and as I said it's very rare > case, but I did see something similar couple of times in the wild. It's > not objection against committing this patch though, in fact I think it > can be committed as is. FWIW, this is definitely a real possibility in any shop that has very high downtime costs and high transaction rates. I also think some kind of clamp is a good idea. It's not that uncommon to run max_connections significantly higher than 100, so the extension could be way larger than 16MB. In those cases this patch could actually make things far worse as everyone backs up waiting on the OS to extend many MB when all you actually needed were a couple dozen more pages. BTW, how was *20 arrived at? ISTM that if you have a lot of concurrent demand for extension that means you're running lots of small DML operations, not really big ones. I'd think that would make *1 more appropriate. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com
В списке pgsql-hackers по дате отправления: