> 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?
Additional memory to maintain the JumbleState data in other structs, and
the additional copy operations.
> 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.
Removing the sticky entry logic will be a big plus, and of course we can
eliminate a query not showing up properly normalized.
> 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?
No lock is held while normalizing, and a shared lock is held while storing,
so there is no apparent benefit from that aspect.
> 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).
Wouldn't be less in terms of memory usage to just store the required
JumbleState fields in Query[Desc]?
clocations_count,
highest_extern_param_id,
clocations_locations,
clocations_length
> > 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.
I can create a separate patch for this.
Regards,
--
Sami Imseih
Amazon Web services
