On Tue, Jul 14, 2020 at 6:09 AM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > Thanks all for the ideas. There have been various points/approaches > discussed in the entire email chain so far. > I would like to summarize all of them here, so that we can agree on > one of the options and proceed further with this feature.
In my opinion, approach #2 seems easy to implement and it's hard to imagine anyone finding much to complain about there, but it's not that powerful either, because it isn't automatic. Now the other approaches have to do with the way in which this should be controlled, and I think there are two separate questions. 1. Should this be controlled by (a) a core GUC, (b) a postgres_fdw GUC, (c) a postgres_fdw server-level option? 2. Should it be (a) a timeout or (b) a Boolean (keep vs. don't keep)? With regard to #1, even if we decided on a core GUC, I cannot imagine that we'd accept enable_connectioncache as a name, because most enable_whatever GUCs are for the planner, and this is something else. Also, underscores between some words but not all words is a lousy convention; let's not do more of that. Apart from those points, I don't have a strong opinion; other people might. With regard to #2, a timeout seems a lot more powerful, but also harder to implement because you'd need some kind of core changes to let the FDW get control at the proper time. Maybe that's an argument for 2(b), but I have a bit of a hard time believing that 2(b) will provide a good user experience. I doubt that most people want to have to decide between slamming the connection shut even if it's going to be used again almost immediately and keeping it open until the end of time. Those are two pretty extreme positions. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
