большую таблицу лить в STDOUT? (ограничен в памяти, целиком лить не вариант, SELECT * FROM с итеративным курсором хотелось бы ускорить)
Запретов нет (о чём прямо написано в документацыи на COPY FROM, кстати).
А каким образом FETCH FORWARD для COPY будет работать?
Я вообще не понял вопроса. FETCH FORWARD -- это какая-то хрень для поэтапной выгрузки запросов из постгреса в продвинутые приложэния, при чём тут COPY?
через пайп лейте сразу куда следует
Так и делаю, но если целиком COPY FROM делать, то памяти не хватает для таблицы (100М строк), поэтому пытаюсь выяснить, как написать COPY FROM, чтобы делал FETCH по 10М к примеру, и лил покусочно через пайп куда надо
а почему, если лить пачками, то память не заканчивается?
Залитая пачка в 10М удаляется из памяти после заливки, освобождается место для следующей
Кому нехватает памяти? Postgres вообще большэ work_mem для этого явно не можэт использовать. Я бы скорее предположыл, что вообще копейки какие-нибудь.
Впервые слышу, чтобы postgres мог хранить таблицы в S3.
Мне стыдно, но я не копенгаген по s3. Память что потребляет? copy оперирует потоком
Так я просто аутпут COPY FROM из STDOUT лью в S3
У COPY FROM нет аутпута, только инпут.
Сорян, оговорился и видимо запутал: COPY * TO STDOUT WITH CSV HEADER > S3
А, так это совсем другое дело. Впрочем, постгрес тут тожэ вряд ли использует большые буфера. И в любом случае они меньшэ work_mem. Там просто итэративное выполнение plan node, с выдачей результата ну буквально по одному пока буфер не забьётся. Так что память переполняется опять, видимо, у вашэй программы. Но чтобы обойти это в copy to можно использовать примерно любой запрос. Не знаю, не уверен насчёт FETCH FROM cursor, но уж поделить на логичного размера таблицу запросами -- вполне реально.
Принял! Благодарю за разъяснения👍👍👍
Обсуждают сегодня