Mentat

Rajmund Hruška wrote in #note-1:

The view 'my queries' shows the queries which contain substring _mentatq(...)_, for example

[...]

The timeline queries look like this:
[...]

I don't really know where to put _mentatq(...)_. Radko Krkoš could you please help me?

Nevermind, I was missing the double quotes.

With timeline queries it's a bit more complicated. When the user presses 'Search' button, there is only one query. But as soon as the first tab is computed - #events - the user can click on the other tabs, each one producing its own query. Now, the user doesn't know which query belongs to which tab.

Also, I am not sure what should happen after the query is canceled. Should the tab stay empty? And then when the tab is clicked on again, should it execute the query again?

Rajmund Hruška wrote in #note-3:

With timeline queries it's a bit more complicated. When the user presses 'Search' button, there is only one query. But as soon as the first tab is computed - #events - the user can click on the other tabs, each one producing its own query. Now, the user doesn't know which query belongs to which tab.

Also, I am not sure what should happen after the query is canceled. Should the tab stay empty? And then when the tab is clicked on again, should it execute the query again?

Oy vey. I'd say the tab should not stay empty, but show some info that the query has been killed. Maybe that's the argument to ditch HTTP error and use the same mechanism (flash banner?) even for events? And yes, the only sane thing is for query to start again when clicked. (User can always modify the query parameters before clicking.)

To identify the user query, 'AS mentatq(ID_xxxxx)' is appended to the query. The queries for the given user are then searched by using regular expressions. But, the query from pg_stat_activity is truncated [1]. So if the query is too long, the query won't be found, as that appendix is added to the end of the query.

So, we can either change the limit of the query length by making a migration or we can come up with a way of having the identifier at the beginning of the query.

[1] https://stackoverflow.com/questions/1135266/queries-in-pg-stat-activity-are-truncated

Jakub, could you please look into it? We need to:

• widen the pg_stat_activity result to actually get the id (migration?) as mentioned in #7656#note-6
• within timeline tab somehow inform the user that his query has been killed as mentioned in #7656#note-5. No need for fancy stuff, as it will probably need a later rehaul with new Boostrap (#7554)

From meeting 2023-06-29:

After widening the pg_stat_activity result size, the PostgreSQL needs to be restarted. We'll leave this on admin, but they need to be informed - so we need to add the bullet into "Upgrading" docs and preferably also into release notes of new stable version.