| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, Bartomiej Romaski <br(at)sentia(dot)pl> |
| Subject: | Re: Planner performance extremely affected by an hanging transaction (20-30 times)? |
| Date: | 2013-11-11 19:48:14 |
| Message-ID: | 11927.1384199294@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> 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.
All of these proposals are pretty scary for back-patching purposes,
anyway. I think what we should consider doing is just changing
get_actual_variable_range() to use a cheaper snapshot type, as in
the attached patch (which is for 9.3 but applies to 9.2 with slight
offset). On my machine, this seems to make the pathological behavior
in BR's test case go away just fine. I'd be interested to hear what
it does in the real-world scenarios being complained of.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| get-actual-variable-range-cheaper.patch | text/x-diff | 3.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sergey Konoplev | 2013-11-11 20:02:56 | Re: postgresql recommendation memory |
| Previous Message | ktm@rice.edu | 2013-11-11 16:26:31 | Re: postgresql recommendation memory |