| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Planner performance extremely affected by an hanging transaction (20-30 times)? |
| Date: | 2013-09-27 21:14:39 |
| Message-ID: | 20130927211439.GB7260@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 2013-09-27 13:57:02 -0700, Josh Berkus wrote:
> Andres, Jeff,
>
>
> >> As far as I can tell, the only downside of doing that is that, since hint
> >> bits might be set later, it is possible some dirty pages will get written
> >> unhinted and then re-dirtied by the hint bit setting, when more aggressive
> >> setting would have only one combined dirty write instead. But that seems
> >> rather hypothetical, and if it really is a problem we should probably
> >> tackle it directly rather than by barring other optimizations.
> >
> > I am - as evidenced - too tired to think about this properly, but I
> > think you might be right here.
>
> Any thoughts on a fix for this we could get into 9.2.5?
I don't see much chance to apply anything like this in a
backbranch. Changing IO patterns in a noticeable way in a minor release
is just asking for trouble.
Also, this really isn't going to fix the issue discussed here - this was
just about the additional ProcArrayLock contention. I don't think it
would change anything dramatical in your case.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ken Tanzer | 2013-09-29 09:09:07 | BASH script for collecting analyze-related info |
| Previous Message | Josh Berkus | 2013-09-27 20:57:02 | Re: Planner performance extremely affected by an hanging transaction (20-30 times)? |