| From: | Markus Schaber <schabi(at)logix-tt(dot)com> |
|---|---|
| To: | Francisco Reyes <lists(at)stringsutils(dot)com> |
| Cc: | Pgsql performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Inserts optimization? |
| Date: | 2006-04-18 09:02:34 |
| Message-ID: | 4444AB2A.5080607@logix-tt.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Hi, Francisco,
Francisco Reyes wrote:
> I only wonder what is safer.. using a second or two in commit_delay or
> using fsync = off.. Anyone cares to comment?
It might be that you misunderstood commit_delay. It will not only delay
the disk write, but also block your connnection until the write actually
is performed.
It will rise the throughput in multi-client scenarios, but will also
rise the latency, and it will absolutely bring no speedup in
single-client scenarios.
It does not decrease safety (in opposite to fsync=off), data will be
consistent, and any application that has successfully finished a commit
can be shure their data is on the platters.[1]
HTH,
Markus
[1] As long as the platters don't lie, but that's another subject.
--
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf. | Software Development GIS
Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Markus Schaber | 2006-04-18 10:51:59 | Re: merge>hash>loop |
| Previous Message | Mikael Carneholm | 2006-04-18 08:51:26 | Re: Migration study, step 2: rewriting queries |