Thank you for your feedback.
> My initial thought is that this patch does not remove the issue of
> loading the entire query text (just to return one or a few entries).
This patch is not intended to address the issue of loading the file
with query texts. We only try to avoid forming and handling tuples
that we don't really need. Forming a tuple in
pg_stat_statements_internal() includes calling CStringGetTextDatum(),
which allocates memory and copies the query text. Avoiding that for
queries we don't need makes a big difference already.
> I do think having the ability to look up a specific entry based on a
> key (that is, hash_search instead of hash_seq_search) would be useful.
That's a great idea, thanks! I'm going to try that and include it in
the next version of the patch if I succeed.
> For what it is worth, I have been thinking about what it would take to
> move query texts into shared memory, which could make this type of
> filtering more practical.
As far as I can tell, pg_stat_statements is storing query texts in an
external file to not have problems with long query texts. Here is a
quote from the docs:
> The representative query texts are kept in an external disk file, and
> do not consume shared memory. Therefore, even very lengthy query texts
> can be stored successfully.
I can think of the idea of caching some of the texts (short enough) in
shared memory. That would require adding a GUC that limits query text
length or maybe that limits the total amount of memory to be used for
caching. So for an individual query, pg_stat_statements should first
look up its text in the cache and only go to the disk if it's not
found. I'm not sure I want to do that, though...
Best regards,
Karina Litskevich
Postgres Professional: http://postgrespro.com/
