Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager |
Дата | |
Msg-id | 15187.1581691360@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [HACKERS] Moving relation extension locks out of heavyweightlock manager
Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager |
Список | pgsql-hackers |
Amit Kapila <amit.kapila16@gmail.com> writes: > I think MaxBackends will generally limit the number of different > relations that can simultaneously extend, but maybe tables with many > partitions might change the situation. You are right that some tests > might suggest a good number, let Mahendra write a patch and then we > can test it. Do you have any better idea? In the first place, there certainly isn't more than one extension happening at a time per backend, else the entire premise of this thread is wrong. Handwaving about partitions won't change that. In the second place, it's ludicrous to expect that the underlying platform/filesystem can support an infinite number of concurrent file-extension operations. At some level (e.g. where disk blocks are handed out, or where a record of the operation is written to a filesystem journal) it's quite likely that things are bottlenecked down to *one* such operation at a time per filesystem. So I'm not that concerned about occasional false-sharing limiting our ability to issue concurrent requests. There are probably worse restrictions at lower levels. regards, tom lane
В списке pgsql-hackers по дате отправления: