タグ付けされた質問 「postgresql-9.3」

画像のハッシュを含む大規模なデータベース（16M行）があります。 妥当な時間枠で距離をハミングすることで行を検索できるようにしたいと思います。 現在、私が問題を適切に理解している限り、ここでの最良の選択肢はBK-Treeを実装するカスタムSP-GiST実装だと思いますが、それは多くの作業のように思われ、まだ実用的ではありませんカスタムインデックスの適切な実装の詳細。ハミング距離を計算すると、扱いやすい十分です、と私はやるけれども、Cを知っています。 基本的に、ここでの適切なアプローチは何ですか？ハッシュの特定の編集距離内で一致を照会できる必要があります。私が理解しているように、等しい長さの文字列を持つレーベンシュタイン距離は機能的にハミング距離です。そのため、そこからインデックスを作成する明確な方法はありませんが、少なくともいくつかの既存のサポートがあります（私が照会している値を思い出してください）変更：固定値からの距離を事前に計算することはできません。 ハッシュは現在、ハッシュのバイナリASCIIエンコード（たとえば「10010101 ...」）を含む64文字の文字列として格納されていますが、十分簡単に​​int64に変換できます。本当の問題は、比較的高速にクエリできる必要があるということです。 私が望むものの線に沿って何かを達成することは可能だと思わpg_trgmれますが、トライグラムマッチングメカニズムがどのように機能するかについては少しわかりません（特に、それが返す類似性メトリックは実際に何を表しますか？編集距離のようなもの）。 挿入のパフォーマンスは重要ではありません（各行のハッシュを計算するのは非常に計算コストがかかります）ので、私は主に検索を気にします。

15 postgresql  index  postgresql-9.3 

PostgreSQL 9.3データベースに2つのテーブルがあります。テーブルにlink_replyは、which_groupテーブルを指すという名前の外部キーがありますlink_group。 link_group関連する行がlink_reply存在しない場所からすべての行を削除したい。基本的には十分に聞こえますが、私はそれに苦労しています。 これはこのように単純なものになりますか（機能しません）？ DELETE FROM link_group WHERE link_reply = NULL;

15 postgresql  join  postgresql-9.3  delete 

postgresql 9.3.10バックエンド（Linux OSに搭載）を備えたDjango Webアプリケーションがあります。ディスクがいっぱいになったエラーが発生したため、テーブルを切り捨てようとしても、次のようなエラーが発生します。 ERROR: could not extend file "base/30137/33186048": No space left on device HINT: Check free disk space. サーバーにディスクスペースを簡単に追加することも、このVM上のものを削除することもできません。ただし、切り捨ての候補となるいくつかのテーブルがありますが、今はそれらを切り捨てることもできないようです。 誰も私がここでできることについてアドバイスをくれますか？これは本番サーバーに大きな打撃を与えており、私はここで少し偶然のDBAをしているので、まったく困惑しています。

14 postgresql  postgresql-9.3 

PostgreSQL 9.3データ型の要素をどのように更新できるかわかりません。 私の例： CREATE TABLE "user" ( id uuid NOT NULL, password character varying(255), profiles json, gender integer NOT NULL DEFAULT 0, created timestamp with time zone, connected timestamp with time zone, modified timestamp with time zone, active integer NOT NULL DEFAULT 1, settings json, seo character varying(255) NOT NULL, …

14 postgresql  update  postgresql-9.3  json 

データベースで毎日実行しているバッチクエリがあります。ただし、アイドル状態のままになっているようで、何が起こっているのかをデバッグするのが非常に困難です。 クエリは、同時に挿入されるテーブルの集計であり、何らかの問題に関連していると推測しています。（集計は前日のデータに基づいているため、挿入は結果に影響しません。） 手がかり これは、sqlalchemyを使用してPythonスクリプト内で実行しています。ただし、トランザクションレベルを自動コミットに設定しているので、トランザクション内に物事がラップされるとは思いません。一方、sqlターミナルでクエリを手動で実行しても、クエリがハングすることはありません。 照会することによりpg_stat_activity、クエリは最初としてデータベースに入ってきますstate='active'。おそらく15秒後に、状態が「アイドル」に変わり、さらにxact_startがに設定されNULLます。待機フラグがtrueに設定されることはありません。 sqlalchemyのトランザクションレベルの自動コミットを理解する前に、代わりに状態'idle in transaction'ではなく状態でハングし'idle'ます。そして、その変更を行ってからハングする可能性がわずかに少なくなりますか？ 私はこれ以上深く掘る準備ができていないように感じます。明確な答えを出さずに、さまざまな状態や関連するpostgres内部についてさらに説明するフィードバックも歓迎します。

13 postgresql  postgresql-9.3 

組み合わせのPostgresの道であるIS DISTINCT FROMとANYかと同じ結果を得るための他のいくつかのきちんとした方法は？ select count(*) from (select 'A' foo union all select 'Z' union all select null) z where foo <> any(array[null, 'A']); count ------- 1 (1 row) select count(*) from (select 'A' foo union all select 'Z' union all select null) z where foo is distinct from any(array[null, 'A']); …

13 postgresql  null  postgresql-9.3 

Ubuntu 12.04および13.04を実行している2つのVMのAPTリポジトリからPostgreSQL 9.3を正常にインストールしましたが、Ubuntu 12.04を実行しているホストマシンに正しくインストールできません。 インストール（今度は）はうまくいったようですが、おそらく私には理解できないエラーがあります： * No PostgreSQL clusters exist; see "man pg_createcluster" Setting up postgresql-9.3 (9.3.0-2.pgdg12.4+1) ... Creating new cluster 9.3/main ... config /etc/postgresql/9.3/main data /var/lib/postgresql/9.3/main locale en_US.UTF-8 port 5432 update-alternatives: using /usr/share/postgresql/9.3/man/man1/postmaster.1.gz to provide /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode. だから、私は自分をPostgreSQLユーザーとして追加しようとしますが、私はこれを取得します： createuser: could not connect to database postgres: could …

13 postgresql  postgresql-9.3 

GRANT USAGE特定のデータベースのユーザー/ロールにしたい。データベースには多くのスキーマがあります。 があることは知っていますがON ALL TABLES IN SCHEMA、「すべてのスキーマ」が必要です。試しましたがGRANT USAGE .. ON DATABASE、それは明らかに間違っています（実際には存在しません）。 これはPostgres 9.3または9.4用で、AWS RDS上にあるサーバーです。

12 postgresql  postgresql-9.3  amazon-rds 

PostgreSQL 9.3のテーブルスペースをから/old/dirに物理的に移動する方法はあり/new/dirますか？mvディレクトリだけを表示して、テーブルスペースがにあることをPostgreSQLに伝えたいと思います/new/dir。以下のように見えるALTER TABLESPACEだけで名前を変更することができます。 新しいテーブルスペースを作成したり、データベースをそこに移動したりすることは避けたいです。これは、多くの時間とディスク領域を必要とする低速なコピープロセスになると思います。私はまた、シンボリックリンク避けたい/old/dirに/new/dir。

12 postgresql  postgresql-9.3 

大量の気象モデルデータをPostgreSQLデータベースに入れています。マシンには8つのコアと16 GBのRAMが搭載されています。PostGIS 2.1でPostgreSQL 9.3を実行しています。各テーブルには、さまざまな気象データ（気温、露点、風など）があります。各テーブルには6〜7列があります。緯度、経度、ポイントジオメトリ、標高、モデルが関連する日時、および対象となる1〜2のデータ値です。データは主に、時間と高度によって境界ボックスを照会されます。テーブルあたり約145,757,360行になります（現在より古いデータはもはや関係がなくなり、削除されます）。テーブルのサイズは、おおよそ、インデックスなしで約10 GBと推定されます。（これは、52バイトのデータと1行あたり23バイトのオーバーヘッドです）。新しいモデルデータが利用可能になると、データは定期的に更新/挿入されます。注意： だから私はこれらの2つの計画を見ています： ポイントジオメトリの追加のインデックスを使用して、（日時、標高）でインデックスを付けてクラスタ化するだけです。古い行を削除し、vacuum / analyzeを実行し、再クラスター化する通常のcronジョブを実行します。 日時でパーティション化し、ジオメトリのインデックスを持つテーブルごとに標高でクラスタ化してインデックス化します。通常のcronジョブを実行して、新しいテーブルを追加し、古いテーブルを削除します。 さらに、 したがって、テーブルを削除する方がはるかに効率的で、削除およびバキューム処理を行うことを知っています。しかし、それ以外の場合はパフォーマンスが向上しますか？ パーティションは、すべてのテーブルが均等に更新されて削除されるまで適切ではない場合に適切ですか（ドキュメントでは、一部のテーブルのみを選択した場合にパーティションが最適に機能することが示されています）？ データを配信する場合、選択はクラスター化インデックスよりも高速になりますか？複数のリクエストが一度に行われる場合、答えは変わりますか？ ありがとうございました。必要なデータをすべて入れてほしい。知らない場合はお知らせください。追加します。

12 postgresql  database-design  partitioning  postgis  postgresql-9.3 

私たちが持っているもの（ソフトウェア）： 基本構成のPostrgeSQL 9.3（変更なしpostgresql.conf） Windows 7 64ビット ハードウェア： インテルCore i7-3770 3.9 Ghz 32 Gb RAM WDC WD10EZRX-00L4HBAtaドライブ（1000Gb、SATA III） したがって、DB aproxにロードする必要があります。bytea列を含む100.000.000行、およびより単純な500.000.000行（LOBなし）。1つ目のテーブルには2つのインデックス（長さ13、19）があり、2つ目のテーブルには2 つのインデックス（長さ18、10）があります。各テーブルのID生成のシーケンスもあります。varcharvarchar 現在、これらの操作は、JDBCバッチサイズ50と並行して8つの接続で実行されています。次の図は、システム負荷を示しています。これはpostgresqlプロセスの負荷がゼロです。24時間のロード後、10.000.000行しかロードしていません。これは非常に遅い結果です。 以下のPostrgreSQL目的で、構成の調整について支援を求めています。 1）この量のデータを超高速でロードする場合、これは1回のみの操作であるため、一時的な構成になる可能性があります。 2）結合やソートを行わずに、インデックスによってこれら2つのテーブルに適度な数のSELECTを実行する本番モードの場合。

12 postgresql-9.3  insert  performance-tuning  database-tuning  bytea 

Postgresでは、次のコードを使用して例外の「スタックトレース」を取得します。 EXCEPTION WHEN others THEN GET STACKED DIAGNOSTICS v_error_stack = PG_EXCEPTION_CONTEXT; これは「自然な」例外では問題なく機能しますが、 RAISE EXCEPTION 'This is an error!'; ...その後、スタックトレースはありません。メーリングリストのエントリによると、これは意図的なものである可能性がありますが、私の人生では理由を理解することはできません。を使用する以外の例外をスローする別の方法を理解したいと思いRAISEます。私は明らかな何かを見逃しているだけですか？誰かがこれのためのトリックを持っていますか？私の選択した文字列を含むPostgresをスローできる例外はありますか？そのため、エラーメッセージで私の文字列だけでなく、完全なスタックトレースも取得しますか？ ここに完全な例があります： CREATE OR REPLACE FUNCTION error_test() RETURNS json AS $$ DECLARE v_error_stack text; BEGIN -- Comment this out to see how a "normal" exception will give you the stack trace RAISE …

11 postgresql  postgresql-9.3  plpgsql  error-handling  exception 

データチェックサムは、9.3で導入された新機能であり、 新しいGUCパラメータ "ignore_checksum_failure"があり、破損が検出された場合でもPostgreSQLにトランザクションの処理を継続させます。 レプリケーションマスターでチェックサムエラーが発生した場合、破損したデータがスレーブにレプリケートされるか、レプリケーションが停止します。の設定に依存しignore_checksum_failureますか？ この READMEには有用な関連情報がいくつかありますが、質問には直接回答しません。

11 postgresql  replication  postgresql-9.3  checksum 

クエリプランナーがpostgresqlでどのように機能するかをよりよく理解しようとしています。 私はこのクエリを持っています： select id from users where id <> 2 and gender = (select gender from users where id = 2) order by latest_location::geometry <-> (select latest_location from users where id = 2) ASC limit 50 私のデータベースでは10ms未満で実行され、usersテーブルには約500kのエントリがあります。 次に、副選択の重複を避けるために、次のようにクエリをCTEとして書き直すことができると考えました。 with me as ( select * from users where id = 2 …

11 postgresql  optimization  postgresql-9.3 

受信データベースで適切な役割を持たずにダンプを復元しようとしています。 ここだけでなくここでも述べた--no-ownerように、オプションとして、pg_dumpまたはpg_restoreその両方が必要です。 次のコマンドラインを使用してダンプを作成しました "C:\Program Files\PostgreSQL\9.3\bin\pg_dump.exe" --no-owner -Ft --dbname=postgresql://avo******:AV0******?@127.0.0.1:5432/BI_DB > K:\BI\backup\sort\bck_%timestamp%.tar 復元線は以下の通り "C:\Program Files\PostgreSQL\9.3\bin\pg_restore.exe" --host localhost --port 5432 --username "postgres" --dbname "BI_TEST2" --no-password --no-owner --role=postgres --exit-on-error --verbose "D:\D\avo\backup\bck_04042017_1410.tar" ご覧のとおり、どちらにも--no-ownerオプションがありますが、最終的には以下のエラーが発生します 私をひどくバグにするのは以下のログです pg_restore: [programme d'archivage (db)] Erreur pendant le traitement de la TOC (« PROCESSING TOC ») : pg_restore: [programme d'archivage (db)] Erreur …

11 postgresql  postgresql-9.3  pg-dump