From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> |
Cc: | William Yu <wyu(at)talisys(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Maximum Possible Insert Performance? |
Date: | 2003-11-25 15:47:37 |
Message-ID: | 27727.1069775257@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> writes:
> William Yu wrote:
>> This is an intriguing thought which leads me to think about a similar
>> solution for even a production server and that's a solid state drive for
>> just the WAL. What's the max disk space the WAL would ever take up?
> Maximum number of WAL segments at any time in 2*(number of checkpoint
> segments)+1 IIRC.
> So if you have 3 checkpoint segments, you can not have more than 7 WAL
> segments at any time. Give or take 1.
I don't believe that's a *hard* limit. The system tries to schedule
checkpoints often enough to prevent WAL from getting bigger than that,
but if you had a sufficiently big spike in update activity, it's at
least theoretically possible that more than checkpoint_segments segments
could be filled before the concurrently running checkpoint finishes and
releases some old segments.
The odds of this being a real problem are small, especially if you don't
try to fit on an undersized SSD by reducing checkpoint_segments. I'd
think that a 512Mb SSD would be plenty of space for ordinary update load
levels ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruno Wolff III | 2003-11-25 16:52:32 | Re: Where to start for performance problem? |
Previous Message | Rob Fielding | 2003-11-25 14:07:58 | Re: Where to start for performance problem? |