Our dual opteron has been performing well for many
weeks now (after some simple tuning) when all of a sudden the queries have
slowed right down!ie:
DUAL 246 OPTERON:
select count(*) from job_archieve; - Time: 107.24 ms
explain analyse select count(*) from
job_archieve;Aggregate (cost=2
Bruce Momjian writes:
> Right now with fsync off you can get transactions partially commited in your
> database, which is a serious problem (think moving money from one account to
> another).
It's worse than that. You can get a totally corrupted database. Things like
duplicated records (the bef
Neil Conway wrote:
> Magnus Hagander wrote:
> > Yes, fsync=false is very good for bulk loading *IFF* you can live with
> > data loss in case you get a crash during load.
>
> It's not merely data loss -- you could encounter potentially
> unrecoverable database corruption.
>
> There is a TODO item
John Allgood wrote:
Hello Again
In the below statement you mention putting each database on its own
raid mirror.
"However, sticking with your arrangement, it would seem that you might be
able to get some extra performance if each database is on it's own raid,
since you are fairly likely to have 2 t
I am no expert, but have been asking them a bunch and I think your missing a
key concept.
The data is best on several drives.
I could be completely off, but if I understood (I just finished doing the
same kind of thing minus several databases) you want your WAL on fast drives
in raid 1 and your da
Hello Again
In the below statement you mention putting each database on its own raid
mirror.
"However, sticking with your arrangement, it would seem that you might be
able to get some extra performance if each database is on it's own raid,
since you are fairly likely to have 2 transactions occuri
No problems my friend :P
I thought that since the beginning and just sent the e-mail to confirm if
there was no software limitation.
Best Wishes,
Bruno Almeida do Lago
-Original Message-
From: Josh Berkus [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 23, 2005 6:02 PM
To: Brun
Hi, Gaetano,
Gaetano Mendola schrieb:
> I have the same requirement too. Actually pg_autovacuum can not be
> instructed "per table" so some time the global settings are not good
> enough. I have a table of logs with 6 milions rows ( 3 years logs )
> I insert on that page ~ 6000 rows for day. I'm
Matthew T. O'Connor wrote:
> Christopher Browne wrote:
>
>> Gaetano Mendola <[EMAIL PROTECTED]> writes:
>>
>>
>>> I do a graph about my disk usage and it's a ramp since one week,
>>> I'll continue to wait in order to see if it will decrease.
>>> I was expecting the steady state at something like
Hi,
RAID1 (mirroring) and RAID1+0 (striping and mirroring) seems to
be a good choice. (RAID 5 is for saving money, but it doesn't have a
good performance)
I suggest you to make a different array for:
- Operating system
- db logs
- each database
It is a little bit of "wasting" disk storage, but
10 matches
Mail list logo
