>> 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.
Here is the second version of the
Here is the third version of the patch. Aleksandra Bondar and I added
some tests. I noticed that the new filtering test runs longer than other
pg_stat_statements tests because of the creation of two databases in it.
I'm thinking of reducing this test a little bit to create only one new
database.
B
Hi hackers,
Aleksandra Bondar and I are proposing the following patch for
pg_stat_statements.
The idea.
-
Currently, to get statistics on a specific query, you should execute
SELECT * FROM pg_stat_statements WHERE queryid = specific_queryid;
This takes a long time because the pg_stat_
> > 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'
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
Hi,
Thanks for raising this.
> This takes a long time because the pg_stat_statements() function forms
> tuples for all statistics it has first, and then they are filtered by
> the WHERE clause.
I am curious about the specific use case where this becomes a concern.
How often are you querying pg_s
