0

psycopg2cursorオブジェクトを使用したPythonの次のコードについて考えてみます（わかりやすくするために、一部の列名が変更または省略されています）。

filename='data.csv'
file_columns=('id', 'node_id', 'segment_id', 'elevated', 
              'approximation', 'the_geom', 'azimuth')
self._cur.copy_from(file=open(filename),
                    table=self.new_table_name, columns=file_columns)
  • データベースは、高速LAN上のリモートマシンにあります。
  • from bashの使用\COPYは、大きな（〜1,000,000行）ファイルの場合でも非常に高速に機能します。

このコードは5,000行に対して超高速ですが、data.csv10,000行を超えると、プログラムは完全にフリーズします。

何か考え\解決策はありますか？

アダム

4

2 に答える 2

5

これは単なる回避策ですが、何かを psql にパイプすることができます。psycopg2 を破壊するのが面倒なときに、このレシピを時々使用します。

import subprocess
def psql_copy_from(filename, tablename, columns = None):
    """Warning, this does not properly quote things"""
    coltxt = ' (%s)' % ', '.join(columns) if columns else ''
    with open(filename) as f:
        subprocess.check_call([
            'psql',
            '-c', 'COPY %s%s FROM STDIN' % (tablename, coltxt),
            '--set=ON_ERROR_STOP=true', # to be safe
            # add your connection args here
        ], stdin=f)

ロックアップに関する限り、複数のスレッドなどを使用していますか?

postgres は、クローズされた接続やデッドロックなどをログに記録していますか? ロックアップ後にディスク アクティビティを確認できますか?

于 2010-08-18T09:39:06.503 に答える
1

これは、open(filename) がすべてのファイルを一度に返すため、「copy_from」がクラッシュするメモリ制限です。これは psycopg2 の問題であり、Postgresql の問題ではないため、Mike のソリューションが最適です。

通常のコミットで「copy_from」を使用し、同時に重複キーを管理する場合の解決策があります: https://stackoverflow.com/a/11059350/1431079

于 2012-06-15T23:44:57.417 に答える