Re: Planner performance extremely affected by an hanging transaction (20-30 times)?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Planner performance extremely affected by an hanging transaction (20-30 times)?
Дата
Msg-id 32089.1393344411@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Planner performance extremely affected by an hanging transaction (20-30 times)?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
I wrote:
> Andres Freund <andres@2ndquadrant.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.

Well, it's three months later, and none of the people who were complaining
so vociferously in this thread seem to have bothered to test the proposed
solution.

However, over at
http://www.postgresql.org/message-id/CAFj8pRDHyAK_2JHSVKZ5YQNGQmFGVcJKcpBXhFaS=vSSCH-vNw@mail.gmail.com
Pavel did test it and reported that it successfully alleviates his
real-world problem.  So I'm now inclined to commit this.  Objections?

            regards, tom lane


В списке pgsql-performance по дате отправления:

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: Bloated tables and why is vacuum full the only option
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Planner performance extremely affected by an hanging transaction (20-30 times)?