| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Christopher Browne <cbbrowne(at)gmail(dot)com>, Maxim Boguk <maxim(dot)boguk(at)gmail(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: BUG #5946: Long exclusive lock taken by vacuum (not full) |
| Date: | 2011-03-25 20:48:23 |
| Message-ID: | 16028.1301086103@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Fri, Mar 25, 2011 at 7:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | DIEGO BALAN | 2011-03-25 20:59:10 | BUG #5951: ERRO NO INICIO DA INSTALACAO |
| Previous Message | Greg Stark | 2011-03-25 20:26:26 | Re: BUG #5946: Long exclusive lock taken by vacuum (not full) |