Re: [PATCH] Increase the maximum value track_activity_query_size

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Bruce Momjian <bruce(at)momjian(dot)us>, Alexey Kondratov <a(dot)kondratov(at)postgrespro(dot)ru>, Robert Haas <robertmhaas(at)gmail(dot)com>, v(dot)makarov(at)postgrespro(dot)ru, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Increase the maximum value track_activity_query_size
Date: 2019-12-21 21:25:05
Message-ID: 25274.1576963505@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> writes:
> Here is what ORMs do:
> select length('SELECT "column_name_1001", "column_name_1002",
> "column_name_1003", "column_name_1004", "column_name_1005",
> "column_name_1006", "column_name_1007", "column_name_1008",
> "column_name_1009", "column_name_1010", "column_name_1011",
> "column_name_1012", "column_name_1013", "column_name_1014",
> "column_name_1015", "column_name_1016", "column_name_1017",
> "column_name_1018", "column_name_1019", "column_name_1020",
> "column_name_1021", "column_name_1022", "column_name_1023",
> "column_name_1024", "column_name_1025", "column_name_1026",
> "column_name_1027", "column_name_1028", "column_name_1029",
> "column_name_1030", "column_name_1031", "column_name_1032",
> "column_name_1033", "column_name_1034", "column_name_1035",
> "column_name_1036", "column_name_1037", "column_name_1038",
> "column_name_1039", "column_name_1040", "column_name_1041",
> "column_name_1042", "column_name_1043", "column_name_1044",
> "column_name_1045", "column_name_1046", "column_name_1047",
> "column_name_1048", "column_name_1049", "column_name_1050" FROM
> "some_table";');
> length
> --------
> 1024
> (1 row)

> That's it – with default settings, you won't see WHERE clause or
> anything else.

If that's true, it doesn't offer much of a case for upping the limit
on track_activity_query_size. The longest such a query could reasonably
get is somewhere near NAMEDATALEN times MaxHeapAttributeNumber, which
as it happens is exactly the existing limit on track_activity_query_size.

> As a result, many queries exceed track_activity_query_size

How? And if they are, why do you care? Such queries sure seem
pretty content-free.

> What is the overhead here except the memory consumption?

The time to copy those strings out of shared storage, any time
you query pg_stat_activity.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2019-12-21 22:02:48 Re: psql small improvement patch
Previous Message Tom Lane 2019-12-21 21:13:04 Re: unsupportable composite type partition keys