On Sun, Nov 20, 2016 at 8:48 PM, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
>> True, but raising the bar for this feature so that it doesn't get done is
>> also bad. It can be improved in a later patch.
>
> I thought you are very strict about performance, so I hesitate to believe you forgive the additional round trip.
libpqfailover is a new feature in v10, so I think it should provide the best user experience for v10 client+server
usersfrom the start. If the concern is the time for development, then support for older releases can be added in a
laterpatch.
>
> There are still several months left for v10. Why don't we try the best? Could you share the difficulty?
I am very strict about regressing the performance of things that we
already have, but I try not to make a policy that a new feature must
be as fast as it could ever be. That could result in us having very
few new features. Of course, it also matters how frequently the
overhead is likely to be incurred. A little overhead on each tuple
visibility check is a much bigger problem than a little overhead on
each CREATE TABLE statement, which in turn is a much bigger problem
than a little overhead on each connection attempt. For good
performance, connections must last a while, so a little extra time
setting one up doesn't seem like a showstopper to me. Anyway, anybody
who finds this mechanism too expensive doesn't have to use it; they
can implement something else instead.
Also, I am not saying that we should not change this in time for v10.
I'm saying that I don't think it should be a requirement for the next
patch to be committed in this area to introduce a whole new mechanism
for determining whether something is a master or a standby. Love it
or hate it, pgsql-jdbc has already implemented something in this area
and it does something useful -- without requiring a wire protocol
change. Now you and Kevin are trying to say that what they did is all
wrong, but I don't agree. There are very many users for whom the
pgsql-jdbc approach will do exactly what they need, and no doubt some
for whom it won't. Getting a patch that mimics that approach
committed is *progress*. Improving it afterwards, whether for v10 or
some later release, is also good.
There is a saying that one should not let the perfect be the enemy of
the good. I believe that saying applies here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company