From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
Cc: | Greg Nancarrow <gregn4422(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, "Smith, Peter" <peters(at)fast(dot)au(dot)fujitsu(dot)com>, David Steele <david(at)pgmasters(dot)net>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)fujitsu(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Dave Cramer <pg(at)fastcrypt(dot)com>, Jing Wang <jingwangian(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Elvis Pranskevichus <elprans(at)gmail(dot)com> |
Subject: | Re: Libpq support to connect to standby server as priority |
Date: | 2020-11-24 21:49:19 |
Message-ID: | 311787.1606254559@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-11-24 21:57:13 | Re: remove spurious CREATE INDEX CONCURRENTLY wait |
Previous Message | Alvaro Herrera | 2020-11-24 21:38:09 | Re: remove spurious CREATE INDEX CONCURRENTLY wait |