Em qui., 10 de nov. de 2022 às 05:16, Michael Paquier <mich...@paquier.xyz> escreveu:
> On Thu, Sep 01, 2022 at 08:42:15AM -0300, Ranier Vilela wrote: > > Let's wait for the patch to be accepted and committed, so we can try to > > change it. > > FWIW, I think that this switch is a good idea for cases where we > potentially update a bunch of tuples, especially based on what > CatalogTupleInsert() tells in its top comment. That's the idea. > Each code path updated > here needs a performance check to see if that's noticeable enough, but > I can get behind the one of CopyStatistics(), at least. > For CopyStatistics() have performance checks. > > EnumValuesCreate() would matter less as this would require a large set > of values in an enum, but perhaps ORMs would care and that should be > measurable. Have a list_length call, for a number of vals. For 2 or more vals, it is already worth it, since CatalogOpenIndexes/CatalogCloseIndexes will be called for each val. > update_attstats() should lead to a measurable difference > with a relation that has a bunch of attributes with few tuples. > Same here. For 2 or more attributes, it is already worth it, since CatalogOpenIndexes/CatalogCloseIndexes will be called for each. DefineTSConfiguration() is less of an issue, still fine to change. > Ok. AddRoleMems() should be equally measurable with a large DDL. As a > whole, this looks pretty sane to me and a good idea to move on with. > One filter, only. For all these functions, the only case that would possibly have no effect would be in the case of changing a single tuple, in which case there would be only one call CatalogOpenIndexes/CatalogCloseIndexes for both paths. > I still need to check properly the code paths changed here, of > course.. > At least, the patch still applies properly. regards, Ranier Vilela
