Re: Block at a time ...

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Block at a time ...
Дата
Msg-id 407d949e1003170252y72d223c3kcc18266140a60997@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Block at a time ...  ("Pierre C" <lists@peufeu.com>)
Ответы Re: Block at a time ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Block at a time ...  (Craig James <craig_james@emolecules.com>)
Re: Block at a time ...  (Bob Lunney <bob_lunney@yahoo.com>)
Список pgsql-performance
On Wed, Mar 17, 2010 at 7:32 AM, Pierre C <lists@peufeu.com> wrote:
>> I was thinking in something like that, except that the factor I'd use
>> would be something like 50% or 100% of current size, capped at (say) 1 GB.

This turns out to be a bad idea. One of the first thing Oracle DBAs
are told to do is change this default setting to allocate some
reasonably large fixed size rather than scaling upwards.

This might be mostly due to Oracle's extent-based space management but
I'm not so sure. Recall that the filesystem is probably doing some
rounding itself. If you allocate 120kB it's probably allocating 128kB
itself anyways. Having two layers rounding up will result in odd
behaviour.

In any case I was planning on doing this a while back. Then I ran some
experiments and couldn't actually demonstrate any problem. ext2 seems
to do a perfectly reasonable job of avoiding this problem. All the
files were mostly large contiguous blocks after running some tests --
IIRC running pgbench.


> Using fallocate() ?

I think we need posix_fallocate().

--
greg

В списке pgsql-performance по дате отправления:

Предыдущее
От: Yeb Havinga
Дата:
Сообщение: Re: GiST index performance
Следующее
От: Greg Smith
Дата:
Сообщение: Re: Building multiple indexes concurrently