| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Scott Carey" <scott(at)richrelevance(dot)com> |
| Cc: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>, "Thomas Finneid" <tfinneid(at)student(dot)matnat(dot)uio(dot)no>, "Craig Ringer" <craig(at)postnewspapers(dot)com(dot)au>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: slow update of index during insert/copy |
| Date: | 2008-09-01 19:41:48 |
| Message-ID: | 873akjodqb.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
"Scott Carey" <scott(at)richrelevance(dot)com> writes:
> On Raid Controllers and Dev machines:
>
> For a dev machine the battery backup is NOT needed.
>
> Battery back up makes a _production_ system faster: In production, data
> integrity is everything, and write-back caching is dangerous without a
> battery back up.
>
> So:
> Without BBU: Write-through cache = data safe in power failure; Write back
> cache = not safe in power failure.
> With BBU : Both modes are safe on power loss.
This could be read the wrong way. With a BBU it's not that you can run the
drives in write-back mode safely. It's that you can cache in the BBU safely.
The drives still need to have their write caches off (ie, in write-through
mode).
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Finneid | 2008-09-01 20:32:56 | Re: slow update of index during insert/copy |
| Previous Message | Pavel Stehule | 2008-09-01 19:17:17 | Re: limit clause breaks query planner? |