{"id":2534,"date":"2010-06-10T09:16:14","date_gmt":"2010-06-10T07:16:14","guid":{"rendered":"http:\/\/code.openark.org\/blog\/?p=2534"},"modified":"2010-06-10T09:16:14","modified_gmt":"2010-06-10T07:16:14","slug":"verifying-group_concat-limit-without-using-variables","status":"publish","type":"post","link":"https:\/\/code.openark.org\/blog\/mysql\/verifying-group_concat-limit-without-using-variables","title":{"rendered":"Verifying GROUP_CONCAT limit without using variables"},"content":{"rendered":"<p>I have a case where I must know if <strong>group_concat_max_len<\/strong> is at its default value (<strong>1024<\/strong>), which means there are some operation I cannot work out. I&#8217;ve ranted on this <a href=\"http:\/\/code.openark.org\/blog\/mysql\/those-oversized-undersized-variables-defaults\">here<\/a>.<\/p>\n<p>Normally, I would simply:<\/p>\n<blockquote>\n<pre class=\"brush: sql; title: ; notranslate\" title=\"\">\r\nSELECT @@group_concat_max_len\r\n<\/pre>\n<\/blockquote>\n<p>However, I am using views, where session variables are not allowed. Using a stored function can <a href=\"http:\/\/code.openark.org\/blog\/mysql\/views-better-performance-with-condition-pushdown\">do the trick<\/a>, but I wanted to avoid stored routines. So here&#8217;s a very simple test case: is the current <strong>group_concat_max_len<\/strong> long enough or not? I&#8217;ll present the long version and the short version.<\/p>\n<h4>The long version<\/h4>\n<blockquote>\n<pre class=\"brush: sql; title: ; notranslate\" title=\"\">\r\nSELECT\r\n  CHAR_LENGTH(\r\n    GROUP_CONCAT(\r\n      COLLATION_NAME SEPARATOR ''\r\n    )\r\n  )\r\nFROM\r\n  INFORMATION_SCHEMA.COLLATIONS;\r\n<\/pre>\n<\/blockquote>\n<p>If the result is <strong>1024<\/strong>, we are in a bad shape. I happen to know that the total length of collation names is above <strong>1800<\/strong>, and so it is trimmed down. Another variance of the above query would be:<!--more--><\/p>\n<blockquote>\n<pre class=\"brush: sql; title: ; notranslate\" title=\"\">\r\nSELECT\r\n  CHAR_LENGTH(\r\n    GROUP_CONCAT(\r\n      COLLATION_NAME SEPARATOR ''\r\n    )\r\n  ) = SUM(CHAR_LENGTH(COLLATION_NAME))\r\n    AS group_concat_max_len_is_long_enough\r\nFROM\r\n  INFORMATION_SCHEMA.COLLATIONS;\r\n\r\n+-------------------------------------+\r\n| group_concat_max_len_is_long_enough |\r\n+-------------------------------------+\r\n|\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0 |\r\n+-------------------------------------+\r\n<\/pre>\n<\/blockquote>\n<p>The <strong>COLLATIONS<\/strong>, <strong>CHARACTER_SETS<\/strong> or <strong>COLLATION_CHARACTER_SET_APPLICABILITY<\/strong> tables provide with known to exist variables (assuming you did not compile MySQL with particular charsets). It&#8217;s possible to <strong>CONCAT<\/strong>, <strong>UNION<\/strong> or <strong>JOIN<\/strong> columns and tables to detect longer than <strong>1800<\/strong> characters in <strong>group_concat_max_len<\/strong>. I admit this is becoming ugly, so let&#8217;s move on.<\/p>\n<h4>The short version<\/h4>\n<p>Don&#8217;t want to rely on existing tables? Not sure what values to expect? Look at this:<\/p>\n<blockquote>\n<pre class=\"brush: sql; title: ; notranslate\" title=\"\">\r\nSELECT CHAR_LENGTH(GROUP_CONCAT(REPEAT('0', 1025))) FROM DUAL\r\n<\/pre>\n<\/blockquote>\n<p><strong>GROUP_CONCAT<\/strong> doesn&#8217;t really care about the number of rows. In the above example, I&#8217;m using a single row (retrieved from the <strong>DUAL<\/strong> virtual table), making sure it is long enough. Type in any number in place of <strong>1025<\/strong>, and you have a metric for your <strong>group_concat_max_len<\/strong>.<\/p>\n<blockquote>\n<pre class=\"brush: sql; title: ; notranslate\" title=\"\">\r\nSELECT\r\n  CHAR_LENGTH(GROUP_CONCAT(REPEAT('0', 32768))) &gt;= 32768 As group_concat_max_len_is_long_enough\r\nFROM\r\n  DUAL;\r\n+-------------------------------------+\r\n| group_concat_max_len_is_long_enough |\r\n+-------------------------------------+\r\n|\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0 |\r\n+-------------------------------------+\r\n<\/pre>\n<\/blockquote>\n<p>The above makes a computation with <strong>REPEAT<\/strong>. One can replace this with a big constant.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I have a case where I must know if group_concat_max_len is at its default value (1024), which means there are some operation I cannot work out. I&#8217;ve ranted on this here. Normally, I would simply: SELECT @@group_concat_max_len However, I am using views, where session variables are not allowed. Using a stored function can do the [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"enabled":false},"version":2}},"categories":[5],"tags":[11,24,21],"class_list":["post-2534","post","type-post","status-publish","format-standard","hentry","category-mysql","tag-configuration","tag-information_schema","tag-sql"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p2bZZp-ES","_links":{"self":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/2534","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/comments?post=2534"}],"version-history":[{"count":24,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/2534\/revisions"}],"predecessor-version":[{"id":2579,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/posts\/2534\/revisions\/2579"}],"wp:attachment":[{"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/media?parent=2534"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/categories?post=2534"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/code.openark.org\/blog\/wp-json\/wp\/v2\/tags?post=2534"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}