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