Re: Libpq support to connect to standby server as priority

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Libpq support to connect to standby server as priority
Дата
Msg-id 325979.1606259987@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Libpq support to connect to standby server as priority  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: Libpq support to connect to standby server as priority
Список pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2020-Nov-24, Tom Lane wrote:
>>> 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.

> Agreed.  If this is just a few hundred bytes of server-side local memory
> per backend, it seems definitely worth it.

Yeah, given the current set of GUC_REPORT variables, it's hard to see
the storage for their last-reported values amounting to much.  The need
for an extra pointer field in each GUC variable record might eat more
space than the actually-live values :-(

            regards, tom lane



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Libpq support to connect to standby server as priority
Следующее
От: David Zhang
Дата:
Сообщение: Add table access method as an option to pgbench