From: | Vinubalaji Gopal <vinubalaji(at)gmail(dot)com> |
---|---|
To: | Vick Khera <vivek(at)khera(dot)org> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: tuning postgresql writes to disk |
Date: | 2011-02-08 00:43:04 |
Message-ID: | AANLkTimYVF6wH31ntHZoc6oQ+qmu3D3imKHgHcjo5+1G@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Thank you. I will try to run some performance tests using the async
commit option. Is there an easy way to find the lost transactions or
does it have to be handled by the application?
On Mon, Feb 7, 2011 at 6:23 AM, Vick Khera <vivek(at)khera(dot)org> wrote:
> On Thu, Feb 3, 2011 at 7:08 PM, Vinubalaji Gopal <vinubalaji(at)gmail(dot)com> wrote:
>> already does this. I looked at the WAL parameters and the new async
>> commit but not sure if I am looking at the right place. Say i have 10
>> clients connecting and each client is inserting a record. I want to
>>
>
> You want the async commit. If you can detect and re-execute "lost"
> transactions, it gives you the best of everything: defer disk I/O and
> transaction boundaries are honored so you never have inconsistent data
> after crash recovery.
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
--
Vinu
In a world without fences who needs Gates?
From | Date | Subject | |
---|---|---|---|
Next Message | AI Rumman | 2011-02-08 05:07:25 | index for ilike operation |
Previous Message | Alex Hunsaker | 2011-02-08 00:34:50 | Re: reindexing |