Re: Libpq support to connect to standby server as priority

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Libpq support to connect to standby server as priority
Дата
Msg-id 311787.1606254559@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Libpq support to connect to standby server as priority  (Anastasia Lubennikova <a.lubennikova@postgrespro.ru>)
Ответы Re: Libpq support to connect to standby server as priority
Список pgsql-hackers
Anastasia Lubennikova <a.lubennikova@postgrespro.ru> writes:
> Hi, this entry is "Waiting on Author" and the thread was inactive for a 
> while. As far as I see, the patch needs some further work.
> Are you going to continue working on it, or should I mark it as 
> "returned with feedback" until a better time?

I'm inclined to go ahead and commit the 0001 patch I posted at [1]
(ie, change the implementation of GUC_REPORT to avoid intra-query
reports), since that addresses a performance problem that's
independent of the goal here.  The rest of this seems to still
be in Greg's court.

Has anyone got an opinion about the further improvement I suggested:

>> As it stands, 0001 reduces the ParameterStatus message traffic to
>> at most one per GUC per query, but it doesn't attempt to eliminate
>> duplicate ParameterStatus messages altogether.  We could do that
>> as a pretty simple adjustment if we're willing to expend the storage
>> to remember the last value sent to the client.  It might be worth
>> doing, since for example the function-SET-clause case would typically
>> lead to no net change in the GUC's value by the end of the query.

On reflection this seems worth doing, since excess client traffic
is far from free.

            regards, tom lane

[1] https://www.postgresql.org/message-id/5708.1601145259%40sss.pgh.pa.us



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: remove spurious CREATE INDEX CONCURRENTLY wait
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: remove spurious CREATE INDEX CONCURRENTLY wait