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

PostgreSQLのすべてのバージョン。そのコンテキストが重要な場合は、postgresql-11などのバージョン固有のタグを追加します。

6
表から「n」個の連続した無料番号を見つける
このような数字のテーブルがあります（ステータスはFREEまたはASSIGNEDです） id_set番号ステータス ----------------------- 1 000001割り当て済み 1 000002無料 1 000003割り当て済み 1 000004無料 1 000005無料 1 000006割り当て済み 10007割り当て済み 1 000008無料 1 000009無料 1 000010無料 1 000011割り当て済み 1 000012割り当て済み 1 000013割り当て済み 1 000014無料 1 000015割り当て済み 「n」個の連続した番号を見つける必要があるため、n = 3の場合、クエリは 1 000008無料 1 000009無料 1 000010無料 各id_setの最初の可能なグループのみを返す必要があります（実際、クエリごとにid_setに対してのみ実行されます） 私はWINDOW関数をチェックしてCOUNT(id_number) OVER (PARTITION BY id_set ROWS UNBOUNDED PRECEDING)いましたが、のようなクエリをいくつか試しましたが、それだけでした:) …
2
PostgreSQLインデックスキャッシング
PostgreSQLでのインデックスのキャッシュ方法に関する「わかりやすい」説明を見つけるのが難しいので、これらの仮定のいずれかまたはすべてを現実的にチェックしたいと思います。 行のようなPostgreSQLインデックスはディスク上に存在しますが、キャッシュされる場合があります。 インデックスは完全にキャッシュ内にある場合とまったくない場合があります。 キャッシュされるかどうかは、それが使用される頻度に依存します（クエリプランナーが定義）。 このため、ほとんどの「賢明な」インデックスは常にキャッシュに置かれます。 インデックスbuffer cacheは行と同じキャッシュ（？）に存在するため、インデックスで使用されるキャッシュスペースは行で使用できません。 これを理解する動機は、データの大部分が決してアクセスされないテーブルで部分インデックスを使用できると示唆された別の質問に続いています。 これを実行する前に、部分インデックスを使用すると2つの利点が得られることを明確にしたいと思います。 キャッシュ内のインデックスのサイズを小さくし、キャッシュ内の行自体により多くのスペースを解放します。 Bツリーのサイズを小さくして、クエリの応答を高速化します。
4
PostgreSQL 9.1ホットバックアップエラー：データベースシステムが起動しています
私はしばらくの間Postgres 9.1のホットバックアップに取り組んできましたが、一貫した問題に遭遇しました。スレーブサーバーでPostgresを再起動すると、pgstartlogログファイルとpg_logディレクトリの下の日次ログファイルがエラーなしで読み込まれます。ただし、psqlコマンドを使用してデータベースに入力しようとすると、エラーが発生します。 FATAL：データベースシステムが起動しています。 また、recovery.confファイルはrecovery.doneにはなりません。私はこのエラーを徹底的に調査し、一貫して同じ応答を見つけました。Postgresを再起動しようとする前にデータベースが完全にシャットダウンされていません。Postgresを再起動した唯一の方法は、service postgresql-9.1 restartor /etc/init.d/postgresql-9.1 restartコマンドを使用することです。このエラーを受け取った後、すべてのプロセスを強制終了し、データベースを再起動しようとしますが、それでも同じエラーを受け取ります。ここからどこへ行くか、この問題を修正する方法が不足しています。以下は、ホットバックアップを完了するために行った正確なプロセスです。 マスターサーバーの構成： pg_hba.conf、次の行を追加しました： ホスト複製postgres IPAddressOfSlaveServer信頼 postgresql.conf： wal_level = hot_standby max_wal_senders = 5 listen_address = '*' ポート= 5432 max_wal_senders = 5 wal_keep_segments = 32 スレーブサーバーの構成： postgresql.conf： hot_standby = on recovery.conf： standby_mode = on primary_conninfo = host = IPAddressOfMasterServer ポート= 5432 ユーザー= postgres restore_command = …
16 postgresql 
2
単純な結合で使用されない主キーのインデックス
次の表とインデックスの定義があります。 CREATE TABLE munkalap ( munkalap_id serial PRIMARY KEY, ... ); CREATE TABLE munkalap_lepes ( munkalap_lepes_id serial PRIMARY KEY, munkalap_id integer REFERENCES munkalap (munkalap_id), ... ); CREATE INDEX idx_munkalap_lepes_munkalap_id ON munkalap_lepes (munkalap_id); munkalap_idのインデックスが次のクエリで使用されないのはなぜですか？ EXPLAIN ANALYZE SELECT ml.* FROM munkalap m JOIN munkalap_lepes ml USING (munkalap_id); QUERY PLAN Hash Join (cost=119.17..2050.88 …
3
PostgreSQL 9.1ストリーミングレプリケーションは、WALアーカイブなしで遅延後に追いつきますか？
環境： Postgres 9.1クラスターでストリーミングレプリケーション/ホットスタンバイを使用しているときに、スタンバイノードがダウンしたとしましょう。これは1日間停止したままで、その間にマスターで多くのDMLが発生します。スタンバイのrecovery.confには「restore_command」エントリは含まれませんが（WALジャーナルファイルからの復元用）、「primary_conninfo」文字列は含まれます（ストリーミングレプリケーション用）。 質問： マスターで1日変更した後、スタンバイを再び開始した場合。ストリーミングレプリケーションのみを使用して、「追いつく」（最終的にはマスターをミラーリングする状態になります）のでしょうか。または、WALファイルアーカイブを有効にし、停止中にアーカイブされたファイルを適用して通貨を確保する必要がありますか？ ここでWALアーカイブ/ストリーミングレプリケーションドキュメントを確認しましたが、WALアーカイブとストリーミングレプリケーションの両方を有効にする必要はないと述べていますが、WALファイルアーカイブを有効にせずにキャッチアップが発生するかどうかは不明です。 ありがとう！
1
ファイル実行時のPostgreSQL終了ステータス
単一のSQLコマンドでPostgreSQLを実行すると、予想どおりエラーコードが返されます。 % psql -c "SELECT * FROM AWDASDASDASDAS" my_db ERROR: relation "awdasdasdasdas" does not exist LINE 1: SELECT * FROM AWDASDASDASDAS % echo $? 1 しかし、ファイルを実行すると、エラーは抑制されます。 % psql -f test.sql my_db psql:test.sql:1: ERROR: relation "awdasdasdasdas" does not exist LINE 1: SELECT * FROM AWDASDASDASDAS % echo $? 0 これらのエラーを取り戻す方法はありますか？
16 postgresql 
4
PostgreSQL：生成された列
PostgreSQLは生成列をサポートしていますか？仮想列とも呼ばれます。私はコラムについて話していません。IDENTITY この注目すべき機能に関する情報は見つかりませんが、SQL ServerおよびMariaDB＆MySQLの最新バージョンで利用できることは知っています。 この機能はSQL：2003標準で言及されており、2006年頃にPostgreSQLフォーラムで議論が行われましたが、この問題に関して実質的なものは見つかりません。 SOについてはいくつかの議論がありますが、現在はかなり古いため、古くなっている可能性があります。
1
postgresql.confファイルの「max_wal_size」および「min_wal_size」パラメーターのデフォルト値を理解する
デフォルト値は、ドキュメントmin_wal_sizeおよびmax_wal_sizeパラメータによると： For max_wal_size：The default is 1 GB For min_wal_size：The default is 80 MB 次に、データベース構成から次のパラメーターを探します。 select name, setting, unit from pg_settings where name in ('min_wal_size', 'max_wal_size') 結果を与える： name | setting | unit ---------------------------------- max_wal_size | 64 | min_wal_size | 5 | 2つの質問があります。 1）これらの値がドキュメントに示されているデフォルト値と一致しないのはなぜですか？構成設定をまったく変更しませんでした。 2）unitこれらのパラメーターの列が空/ NULLである理由 この場合、64と5の値はどういう意味ですか？MB？GB？または何？ work_memすべてが明確な場合、これがパラメーターの例とは異なる理由 ： name | setting …
2
個別選択を高速化する方法は？
私はいくつかの時系列データで単純な選択を区別しています： SELECT DISTINCT user_id FROM events WHERE project_id = 6 AND time > '2015-01-11 8:00:00' AND time < '2015-02-10 8:00:00'; そして、それは112秒かかります。クエリプランは次のとおりです。 http://explain.depesz.com/s/NTyA 私のアプリケーションは、多くの異なる操作を実行する必要があり、このようにカウントします。この種のデータを取得するより速い方法はありますか？
1
Postgresデータベースの復元：pg_restore -vs-ちょうどpsqlを使用して
pg_dump（プレーンテキスト形式）を使用してPostgresデータベースをダンプし、psql（-fオプション付き）を使用して単純に復元します。 どちらが質問を請います：pg_restoreを使用しないことで何かが欠けているのpsqlですか？ pg_dumpパラメーターを使用して、トリガーの無効化などのオプションを制御できます。それでは、何のpg_restoreために使われますか？非プレーンテキストダンプフォーマット？
2
JSONBを使用したPostgreSQLの参加
私はこのSQLを持っています： CREATE TABLE test(id SERIAL PRIMARY KEY, data JSONB); INSERT INTO test(data) VALUES ('{"parent":null,"children":[2,3]}'), ('{"parent":1, "children":[4,5]}'), ('{"parent":1, "children":[]}'), ('{"parent":2, "children":[]}'), ('{"parent":2, "children":[]}'); それは与えるだろう： id | data ----+-------------------------------------- 1 | {"parent": null, "children": [2, 3]} 2 | {"parent": 1, "children": [4, 5]} 3 | {"parent": 1, "children": []} 4 | {"parent": …
1
テーブルフィルファクターとインデックスフィルファクターの違い
Postgresでは、テーブルだけでなくインデックスにもfillfactorを設定できます。違いはなんですか？いずれかの値を決定する方法。ユースケースは何ですか？ 空間インデックスで空間リレーションをクラスター化しようとしています。数百万のレコードがあります。毎日新しいレコードが作成されることはほとんどありませんが、レコードは常に更新されます。 ユースケースは空間範囲クエリです。テーブルのfillfactorおよび/またはindex fillfactorの適切な値は何ですか？
16 postgresql 
2
PL / pgSQLでクエリが結果を返さないかどうかを確認する簡単な方法はありますか？
私は現在PL / pgSQLを少し実験していますが、次のようなもっとエレガントな方法があるかどうか知りたいです： select c.data into data from doc c where c.doc_id = id and c.group_cur > group_cur order by c.id desc limit 1; EXCEPTION WHEN NO_DATA_FOUND THEN select c.data into data from doc c where c.doc_id = id and c.global_cur > global_cur order by c.id desc limit 1; EXCEPTION …
3
Postgresサーバーのタイムアウトを制限することは可能ですか？
アプリケーション（クライアント側）で接続とコマンドのタイムアウトを10分に設定します。 私のアプリケーションよりも簡単なクエリを実行します： SELECT pg_sleep(65) 一部のサーバーでは正常に動作しますが、他のサーバーは60秒後に接続を閉じます。 これは、タイムアウトを制限し、クライアント設定を無視するPostgreSQLサーバーの構成のようなものでしょうか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.