| From: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
|---|---|
| To: | Magnus Hagander <magnus(at)hagander(dot)net> |
| Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Doc patch making firm recommendation for setting the value of commit_delay |
| Date: | 2012-11-15 10:44:20 |
| Message-ID: | CAEYLb_WmuYuV_K+RatgbkLZ99NH1UY-4=HND9Nieiko5upsOew@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 15 November 2012 10:04, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> I would rather see this just turn into one of the things a more general
>> tuning tool knew how to do, executing against a fully setup system. Having a
>> useful implementation of commit_delay and useful docs on it seems like
>> enough of a jump forward for one release. Moving fully into auto-tuning
>> before getting more field feedback on how that works out is pretty
>> aggressive.
>
> +1.
I am inclined to agree. I did attempt to use the instrumentation
macros to have commit_delay set adaptively at runtime, which would
have at least addressed this concern, but that just didn't work as
well as this.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2012-11-15 10:44:41 | Re: feature proposal - triggers by semantics |
| Previous Message | Amit Kapila | 2012-11-15 10:39:42 | Re: WIP patch for hint bit i/o mitigation |