From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
cc: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>,
        Greg Nancarrow <gregn4422@gmail.com>,
        Peter Smith <smithpb2250@gmail.com>,
        "Smith,
    Peter" <peters@fast.au.fujitsu.com>,
        David Steele <david@pgmasters.net>,
        "Tsunakawa,
    Takayuki" <tsunakawa.takay@fujitsu.com>,
        Haribabu Kommi <kommi.haribabu@gmail.com>,
        Robert Haas <robertmhaas@gmail.com>,
        Laurenz Albe <laurenz.albe@cybertec.at>,
        Dave Cramer <pg@fastcrypt.com>, Jing Wang <jingwangian@gmail.com>,
        PostgreSQL-development <pgsql-hackers@postgresql.org>,
        Elvis Pranskevichus <elprans@gmail.com>
Subject: Re: Libpq support to connect to standby server as priority
In-reply-to: <20201124225917.GA21884@alvherre.pgsql>
References: <20201124225917.GA21884@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@alvh.no-ip.org>
	message dated "Tue, 24 Nov 2020 19:59:17 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <325978.1606259987.1@sss.pgh.pa.us>
Date: Tue, 24 Nov 2020 18:19:47 -0500
Message-ID: <325979.1606259987@sss.pgh.pa.us>
Precedence: bulk

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