Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cDZkt-0002Zz-4H for pgsql-general@arkaria.postgresql.org; Sun, 04 Dec 2016 16:35:11 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cDZks-0002Vy-4Z for pgsql-general@arkaria.postgresql.org; Sun, 04 Dec 2016 16:35:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cDZiX-0005cq-Cy for pgsql-general@postgresql.org; Sun, 04 Dec 2016 16:32:45 +0000 Received: from mail-io0-x234.google.com ([2607:f8b0:4001:c06::234]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cDZiU-0007JC-21 for pgsql-general@postgresql.org; Sun, 04 Dec 2016 16:32:44 +0000 Received: by mail-io0-x234.google.com with SMTP id c21so516196239ioj.1 for ; Sun, 04 Dec 2016 08:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=2C70XRALRO4pvEWzTHdziOuBtwj01X1WfrIOEI8Vi8s=; b=ti7iJ8YgxxEAm5x2pjkWFMx6/IDXnPAPxDn841h7caIqw4ugjA7Taq00jis9hDLo6R zHh1HmeNAwYTBd5sMJq35k0P98fv/nbPySXaX5Gl0rXcwFnSm9E9mRWCS+1eDG54FlvS wqLwgBjNTBRqELcZnds1RJvuN5ZsFx4iMJBRSYpUMN2q0mI+8d4BN4uziOL3fpks4Hzm +Ziu0VmjS/dRd78G6nRvY/achGTjuzNuDOMxX5cgLkzqT1WWCmROOd4Iyn13N0843Juj 1LBqkjsv036RS5sE8jM/7HCkmUITTyXiSzQqAVzvc8KPM4tjBlaTGF8+RlMeum82gq5l P+RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=2C70XRALRO4pvEWzTHdziOuBtwj01X1WfrIOEI8Vi8s=; b=bbJRzE59i+auMQqhpZ3IDY8dMCzHIH5Eaxnj8PIGeqBmNE1W1xPDmixkqlKdEJrjB/ US5gElS92rkGZDoibtFXM6wI7GHWXTNatJGors+lFE21GQRxXWgOXUniZT//Z1B1n9u8 6Xigztb+x0ug/wPHYTrTBPYBV8uz66n5dyNIwdYxjpit634RRzkMOEL2Dnqz40gPege5 4JNl1eLUQIXwPegGY5C1YOS309a+TMY2UPabv9xjfwuDOkiBf3rX0rjEVevoJ8QS9hYJ KhSYr3P1ZeuW6/nDTur6nNY9e+EVqliOG5/mVE/DlI/flynuQOjNLiINFcyMAezOHAgl SsEg== X-Gm-Message-State: AKaTC00oEEyRJCNYfc6vOliu4jwsmCT0cYlaHRxnEOgP4b0sUxEWPYahxm2qzNXxDUkrFA== X-Received: by 10.107.18.211 with SMTP id 80mr46564051ios.14.1480869158923; Sun, 04 Dec 2016 08:32:38 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id l3sm4760193iti.3.2016.12.04.08.32.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Dec 2016 08:32:38 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id DA1B8801E60; Sun, 4 Dec 2016 10:32:37 -0600 (CST) Date: Sun, 4 Dec 2016 10:32:37 -0600 From: Justin Pryzby To: pgsql-general@postgresql.org Subject: INSERT ON CONFLICT of "wide" table: target lists can have at most 1664 entries Message-ID: <20161204163237.GA8030@telsasoft.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="WIyZ46R2i8wDzkSu" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-general Precedence: bulk Sender: pgsql-general-owner@postgresql.org --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Our application INSERTs data from external sources, and infrequently UPDATEs the previously-inserted data (currently, it first SELECTs to determine whether to UPDATE). I'm implementing unique indices to allow "upsert" (and pg_repack and..), but running into a problem when the table has >830 columns (we have some tables which are at the 1600 column limit, and have previously worked around that limit using arrays or multiple tables). I tried to work around the upsert problem by using pygresql inline=True (instead of default PREPAREd statements) but both have the same issue. I created a test script which demonstrates the problem (attached). It seems to me that there's currently no way to "upsert" such a wide table? I see: ./src/include/access/htup_details.h:#define MaxTupleAttributeNumber 1664 /* 8 * 208 */ ./src/backend/parser/parse_node.c- /* ./src/backend/parser/parse_node.c- * Check that we did not produce too many resnos; at the very least we ./src/backend/parser/parse_node.c- * cannot allow more than 2^16, since that would exceed the range of a ./src/backend/parser/parse_node.c: * AttrNumber. It seems safest to use MaxTupleAttributeNumber. ./src/backend/parser/parse_node.c- */ ./src/backend/parser/parse_node.c: if (pstate->p_next_resno - 1 > MaxTupleAttributeNumber) ./src/backend/parser/parse_node.c- ereport(ERROR, ./src/backend/parser/parse_node.c- (errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED), ./src/backend/parser/parse_node.c: errmsg("target lists can have at most %d entries", ./src/backend/parser/parse_node.c: MaxTupleAttributeNumber))); Thanks in advance for any suggestions. Justin --WIyZ46R2i8wDzkSu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="wide_upsert.txt" #! /bin/sh set -e n=831 t=wide_upsert psql -c "DROP TABLE IF EXISTS $t" cols='id int' vals='0' sets='id=0' for a in `seq -w 0 $n` do c="c$a int" cols="$cols, c$a int" vals="$vals, \$1" sets="$sets, c$a=\$1" done echo $cols psql -c "CREATE TABLE $t ($cols, PRIMARY KEY (id))" set -x psql -c "PREPARE x AS INSERT INTO $t VALUES ($vals) ON CONFLICT (id) DO UPDATE SET $sets; EXECUTE x(0)" --WIyZ46R2i8wDzkSu Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general --WIyZ46R2i8wDzkSu--