On Sun, Nov 20, 2016 at 8:48 PM, Tsunakawa, Takayuki <tsunakawa.ta...@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. libpq failover is a new feature in v10, > so I think it should provide the best user experience for v10 client+server > users from the start. If the concern is the time for development, then > support for older releases can be added in a later patch. > > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers