| From: | Alex Turner <armtuk(at)gmail(dot)com> |
|---|---|
| To: | Kelly Burkhart <kelly(at)tradebotsystems(dot)com> |
| Cc: | Ron <rjpeace(at)earthlink(dot)net>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Need for speed 2 |
| Date: | 2005-09-20 15:35:58 |
| Message-ID: | 33c6269f05092008357973a651@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
I have found that while the OS may flush to the controller fast with
fsync=true, the controller does as it pleases (it has BBU, so I'm not too
worried), so you get great performance because your controller is determine
read/write sequence outside of what is being demanded by an fsync.
Alex Turner
NetEconomist
On 8/25/05, Kelly Burkhart <kelly(at)tradebotsystems(dot)com> wrote:
>
> On Thu, 2005-08-25 at 11:16 -0400, Ron wrote:
> > ># - Settings -
> > >
> > >fsync = false # turns forced synchronization on or off
> > >#wal_sync_method = fsync # the default varies across platforms:
> > > # fsync, fdatasync, open_sync, or
> >
> > I hope you have a battery backed write buffer!
>
> Battery backed write buffer will do nothing here, because the OS is
> taking it's sweet time flushing to the controller's battery backed write
> buffer!
>
> Isn't the reason for batter backed controller cache to make fsync()s
> fast?
>
> -K
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | evgeny gridasov | 2005-09-20 16:02:10 | Re: RAID Stripe size |
| Previous Message | Alex Turner | 2005-09-20 15:33:29 | Re: RAID Stripe size |