On Sat, Feb 25, 2023 at 01:59:04PM +0000, Imseih (AWS), Sami wrote: > The overhead of storing this additional private data for the life of the query > execution may not be desirable.
Okay, but why? > I think we also will need to copy the > private data to QueryDesc as well to make it available to planner/utility/exec > hooks. This seems like the key point to me here. If we copy more information into the Query structures, then we basically have no need for sticky entries, which could be an advantage on its own as it simplifies the deallocation and lookup logic. For a DML or a SELECT, the manipulation of the hash table would still be a three-step process (post-analyze, planner and execution end), but the first step would have no need to use an exclusive lock on the hash table because we could just read and copy over the Query the normalized query if an entry exists, meaning that we could actually relax things a bit? This relaxation has as cost the extra memory used to store more data to allow the insertion to use a proper state of the Query[Desc] coming from the JumbleState (this extra data has no need to be JumbleState, just the results we generate from it aka the normalized query). > In v14, we added a dealloc metric to pg_stat_statements_info, which is > helpful. > However, this only deals with the pgss_hash entry deallocation. > I think we should also add a metric for the text file garbage collection. This sounds like a good idea on its own. -- Michael
signature.asc
Description: PGP signature