Re: Performance degradation in commit ac1d794
От | Tom Lane |
---|---|
Тема | Re: Performance degradation in commit ac1d794 |
Дата | |
Msg-id | 23665.1455216080@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Performance degradation in commit ac1d794 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Performance degradation in commit ac1d794
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Thu, Feb 11, 2016 at 1:19 PM, Andres Freund <andres@anarazel.de> wrote: >> Well, I can't do anything about that right now. I won't have the time to >> whip up the new/more complex API we discussed upthread in the next few >> days. So either we go with a simpler API (e.g. pretty much a cleaned up >> version of my earlier patch), revert the postmaster deatch check, or >> somebody else has to take lead in renovating, or we wait... > Well, I thought we could just revert the patch until you had time to > deal with it, and then put it back in. That seemed like a simple and > practical option from here, and I don't think I quite understand why > you and Tom don't like it. Don't particularly want the git history churn, if we expect that the patch will ship as-committed in 9.6. If it becomes clear that the performance fix is unlikely to happen, we can revert then. If the performance change were an issue for a lot of testing, I'd agree with a temporary revert, but I concur with Andres that it's not blocking much. Anybody who does have an issue there can revert locally, no? regards, tom lane
В списке pgsql-hackers по дате отправления: