Re: INSERT ON CONFLICT of "wide" table: target lists can have at most 1664 entries
В списке pgsql-general по дате отправления:
| От | Gmail |
|---|---|
| Тема | Re: INSERT ON CONFLICT of "wide" table: target lists can have at most 1664 entries |
| Дата | |
| Msg-id | 00F6777D-4500-4FEF-9BCE-0D1A22C1A2AB@gmail.com обсуждение |
| Ответ на | INSERT ON CONFLICT of "wide" table: target lists can have at most 1664 entries (Justin Pryzby <pryzby@telsasoft.com>) |
| Список | pgsql-general |
> On Dec 4, 2016, at 9:32 AM, Justin Pryzby <pryzby@telsasoft.com> wrote: > > 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? Pardon my intrusion here, but I'm really curious what sort of datum has so many attributes?
В списке pgsql-general по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера