Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
Subject: Re: INSERT ON CONFLICT of "wide" table: target lists can have at most
 1664 entries
From: Gmail <robjsargent@gmail.com>
In-Reply-To: <20161204163237.GA8030@telsasoft.com>
Date: Sun, 4 Dec 2016 09:52:45 -0700
Cc: pgsql-general@postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <00F6777D-4500-4FEF-9BCE-0D1A22C1A2AB@gmail.com>
References: <20161204163237.GA8030@telsasoft.com>
To: Justin Pryzby <pryzby@telsasoft.com>
Precedence: bulk
Sender: pgsql-general-owner@postgresql.org


> On Dec 4, 2016, at 9:32 AM, Justin Pryzby <pryzby@telsasoft.com> wrote:
>=20
> Our application INSERTs data from external sources, and infrequently UPDA=
TEs
> the previously-inserted data (currently, it first SELECTs to determine wh=
ether
> to UPDATE).
>=20
> 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 tabl=
es
> which are at the 1600 column limit, and have previously worked around that
> limit using arrays or multiple tables).
>=20
> I tried to work around the upsert problem by using pygresql inline=3DTrue
> (instead of default PREPAREd statements) but both have the same issue.
>=20
> I created a test script which demonstrates the problem (attached).
>=20
> It seems to me that there's currently no way to "upsert" such a wide tabl=
e?

Pardon my intrusion here, but I'm really curious what sort of datum has so =
many attributes?


--=20
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general