Yuriy,
I think, for the sake of code simplicity we can track all queries.
in other case we will need to parse SQL text and detect that current query
is the EXPLAIN one.
--
Alexey Kuznetsov
Hi,
I have question related to subject. How do you think should we track
EXPLAIN queries also? I see reasons as to skip it and as include to history:
pros:
We will have full picture and see all queries.
cons:
Such queries can be considered as investigate/debug/service queries and can
push out
Yuri, Vladimir,
How expensive will it be to have the history enabled by default? For
instance, let's take the running queries mechanics as an example, what is
the performance impact the did?
As for the running queries, Yuri, if it's completed please send a summary
to the relevant discussion expla
Vladimir, thanks for your expert opinion.
I have some thoughts about 5 point.
I tried to find how it works for Oracle and PG:
*PG*: keep by default 1000 (can be configured) statements without and
discard the least-executed statements. Update statistics is asynchronous
process and statistics may h
Hi,
I'd propose the following approach:
1) Enable history by default. Becuase otherwise users will have to restart
the node to enable it, or we will have to implement dynamic history enable,
which is complex thing. Default value should be relatively small yet
allowing to accommodate typical worklo
Alexey,
Yes, such property to configuration history size will be added. I think
default value should be 0 and history by default shouldn't be gather at
all, and can be switched on by property in case when it required.
Currently I planned use the same way to evicting old data as for
queryMetrics -
Yuriy,
I have several questions:
Are we going to add some properties to cluster configuration for history
size?
And what will be default history size?
Will the same queries count as same item of historical data?
How we will evict old data that not fit into history?
Will we somehow count "redu
