On Mon, Oct 12, 2020 at 10:14 AM Bruce Momjian <br...@momjian.us> wrote: > On Mon, Oct 12, 2020 at 04:20:05PM +0800, Julien Rouhaud wrote: > > But there are many people that aren't happy with the current hashing > > approach. If we're going to move the computation in core, shouldn't > > we listen to their complaints and let them pay some probably quite > > high overhead to base the hash on name and/or fully qualified name > > rather than OID? > > For instance people using logical replication to upgrade to a newer > > version may want to easily compare query performance on the new > > version, or people with multi-tenant databases may want to ignore the > > schema name to keep a low number of different queryid. > > Well, we have to consider how complex the user interface has to be to > allow more flexibility. We don't need to allow every option a user will > want. > > With a version number, we have the ability to improve the algorithm or > add customization, but for the first use, we are probably better off > keeping it simple.
I thought your earlier idea of allowing this to be controlled by a GUC was good. There could be a default method built into core, matching what pg_stat_statements does, so you could select no hashing or that method no matter what. Then extensions could provide other methods which could be selected via the GUC. I don't really understand how a version number helps. It's not like there is going to be a v2 that is in all ways better than v1. If there are different algorithms here, they are going to be customized for different needs. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
