Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
От | Tom Lane |
---|---|
Тема | Re: BUG #5946: Long exclusive lock taken by vacuum (not full) |
Дата | |
Msg-id | 16028.1301086103@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #5946: Long exclusive lock taken by vacuum (not full) (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
Re: BUG #5946: Long exclusive lock taken by vacuum (not full) |
Список | pgsql-bugs |
Greg Stark <gsstark@mit.edu> writes: > On Fri, Mar 25, 2011 at 7:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I don't recall any particular discussion of making the user contend with >> that. My thought would be to do something like enlarging the table by >> 10% anytime we need to extend it. > Just for reference this is how Oracle *used* to behave. It was widely > hated and led to all sorts of problems. Best practice was to pick a > reasonable size for your tablespace and pre-allocate that size and set > future increments to be that size with 0% growth. Interesting, but I don't understand/believe your argument as to why this is a bad idea or fixed-size extents are better. It sounds to me just like the typical Oracle DBA compulsion to have a knob to twiddle. A self-adjusting enlargement behavior seems smarter all round. regards, tom lane
В списке pgsql-bugs по дате отправления: