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)  (Greg Stark <gsstark@mit.edu>)
Re: BUG #5946: Long exclusive lock taken by vacuum (not full)  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: BUG #5946: Long exclusive lock taken by vacuum (not full)
Следующее
От: Greg Stark
Дата:
Сообщение: Re: BUG #5946: Long exclusive lock taken by vacuum (not full)