statements is often accessed by monitoring and reporting tools, and
it will be a good idea to have
the data here in the structured and easily parsed format.
Thank you,
Sergei Agalakov
work_mem before
execution, and then return it back like
SET work_mem = '512MB';
... run your query
RESET work_mem;
Regards,
Sergei Agalakov
On 12/2/2018 2:22 AM, legrand legrand wrote:
I'm also very interested by collecting "search_path" information for
statements,
but this information may not be unique for pg_stat_statements key
(dbid,userid,queryid) ...
How would this 1-N relation be handled ?
1/ just catch initial session_info
I have renamed the thread [PROPOSAL] extend the object names to the
qualified names in pg_stat_statements
started on
https://www.postgresql.org/message-id/9baf5c06-d6ab-c688-010c-843348e3d98c%40gmail.com
and ended on
On 11/29/2018 12:46 PM, Tom Lane wrote:
Alvaro Herrera writes:
On 2018-Nov-28, Tom Lane wrote:
Color me skeptical --- ruleutils has never especially been designed
to be fast, and I can't see that the overhead of this is going to be
acceptable to anybody who needs pg_stat_statements in
On 11/29/2018 10:59 AM, Stephen Frost wrote:
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
On 2018-Nov-28, Tom Lane wrote:
Alvaro Herrera writes:
On 2018-Nov-28, Tom Lane wrote:
This would also entail rather significant overhead to find out schema
names and interpolate them
On 11/29/2018 10:47 AM, Alvaro Herrera wrote:
On 2018-Nov-28, Tom Lane wrote:
Alvaro Herrera writes:
On 2018-Nov-28, Tom Lane wrote:
This would also entail rather significant overhead to find out schema
names and interpolate them into the text.
True. I was thinking that the
It's a real problem. I saw this pattern more than once already.
The people have several schemas with identical data structures as a
preparation to eventual migration of the schema to its own server in the
cloud.
So you have ten schemas, one generic user from connection pool and
scripts and tools.
Thank you,
Sergei Agalakov
It was discussed in pgsql-general, and now it seems to be ready as a
proposal to pgsql-hackers.
https://www.postgresql.org/message-id/372d75cc-053b-1a07-948f-089408d3c...@gmail.com
