From: | Guillaume Cottenceau <gc(at)mnc(dot)ch> |
---|---|
To: | "pgsql-performance\(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: which ext3 fs type should I use for postgresql |
Date: | 2008-05-15 15:56:31 |
Message-ID: | 87lk2bwogg.fsf@mnc.ch |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Joshua D. Drake" <jd 'at' commandprompt.com> writes:
> Guillaume Cottenceau wrote:
>> Matthew Wakeling <matthew 'at' flymine.org> writes:
>
>> It is still relevant, as with 5% margin, you can afford changing
>> that to 0% with tune2fs, just the time for you to start PG and
>> remove some data by SQL, then shutdown and set the margin to 5%
>> again.
>
> I find that if you actually reach that level of capacity failure it is
> due to lack of management and likely there is much lower hanging fruit
> left over by a lazy dba or sysadmin than having to adjust filesystem
> level parameters.
>
> Manage actively and the above change is absolutely irrelevant.
Of course. I didn't say otherwise. I only say that it's useful in
that case. E.g. if you're using a dedicated partition for PG,
then a good solution is what I describe, rather than horrifyingly
trying to remove some random PG files, or when you cannot
temporarily move some of them and symlink from the PG partition.
I don't praise that kind of case, it should of course be avoided
by sane management. A bad management is not a reason for hiding
solutions to the problems that can happen!
--
Guillaume Cottenceau
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-05-15 16:19:14 | Re: I/O on select count(*) |
Previous Message | Alvaro Herrera | 2008-05-15 15:52:32 | Re: I/O on select count(*) |