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

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

2
インデックスを追加することのコスト/メリットを判断するにはどうすればよいですか?
クレイグ・リンガーによると: 通常、参照側の外部キー列(またはそれを含む)にインデックスを作成することをお勧めしますが、必須ではありません。追加するインデックスごとにDML操作が少し遅くなるためINSERT、UPDATEまたはごとにパフォーマンスコストが発生しDELETEます。インデックスがめったに使用されない場合、その価値はないかもしれません。 インデックスを追加するメリットがコストを上回るかどうかをどのように判断しますか? インデックスを追加する前後に単体テストのプロファイルを作成し、全体的なパフォーマンスの向上を確認しますか?それとももっと良い方法がありますか?

2
行の見積もりが大幅に不正確であるため、フルテキスト検索が遅い
このデータベースに対するフルテキストクエリ(RT(リクエストトラッカー)チケットを格納する)は、実行に非常に長い時間がかかるようです。添付ファイルテーブル(フルテキストデータを含む)は約15GBです。 データベーススキーマは次のとおりで、約200万行です。 rt4 =#\ d +添付ファイル テーブル "public.attachments" コラム| タイプ| 修飾子| ストレージ| 説明文 ----------------- + ----------------------------- +- -------------------------------------------------- ------ + ---------- + ------------- id | 整数| nullではないデフォルトのnextval( 'attachments_id_seq' :: regclass)| プレーン| transactionid | 整数| nullではない| プレーン| 親| 整数| nullではないデフォルト0 | プレーン| メッセージID | キャラクター変化(160)| | 拡張| 件名| 文字の変化(255)| | 拡張| …

2
PL / pgSQL関数でレコードを返す-クエリを高速化する
私が持っているPerlで書かれた非フォークゲームデーモンのPostgreSQL 9.3データベースに書き込みプレーヤー統計にacyncクエリを使用しています、。しかし、データベースから何かを読み取る必要がある場合(プレーヤーが禁止されている場合や、プレーヤーにVIPステータスがある場合など)は、同期クエリを使用します。 これにより、データベースから値が読み取られるまで、ゲームが一瞬停止します。 値を読み取るために非同期クエリを使用するようにゲームデーモンを書き換えることはできません(試してみましたが、変更が多すぎました)。私の質問は、いくつかの無関係なクエリを組み合わせることは理にかなっています(新しいプレーヤーの場合に行う必要があることです)接続)を1つのプロシージャに追加し、Perlプログラムに同時にいくつかの値を返すにはどうすればよいですか? 現在のクエリはすべて、プレーヤーIDをパラメーターとして取り、1つの値を返します。 -- Has the player been banned? select true from pref_ban where id=? -- What is the reputation of this player? select count(nullif(nice, false)) - count(nullif(nice, true)) as rep from pref_rep where id=? -- Is he or she a special VIP player? select vip > now() …

1
再帰CTEのカーディナリティを「ヒント」にするにはどうすればよいですか?
最小限の例として次の再帰CTEを使用していますが、一般的に、オプティマイザは再帰CTEにデフォルトの「推測」カーディナリティを使用する必要があります。 with recursive w(n) as ( select 1 union all select n+1 from w where n<5 ) select * from w; /* n --- 1 2 3 4 5 */ explain analyze with recursive w(n) as ( select 1 union all select n+1 from w where n<5 ) select * …

2
PostgreSQLデータベース接続の数を適切に監視するにはどうすればよいですか?
Nagiosスクリプトを使用してPostgresデータベース上のデータベース接続の数を監視しようとしたところ、この問題が発生しました。これらは現在開いている接続としてカウントされ、5分ごとに測定されます。 SELECT sum(numbackends) FROM pg_stat_database; それでも、これは多数の短期間の接続を見逃しているようで、統計は現実とはかけ離れています。 スクリプトを手動で実行してみましたが、2秒の接続が数秒離れた2つの接続の間でも大きな変化が見られました。 この情報を信頼できる方法で取得するにはどうすればよいですか?時間間隔中に発生したmax(connectios)など。

1
550万行/ドキュメントのMongoDBパフォーマンスとPostgreSQL
誰かがこれらのクエリを比較して、PostgreSQLクエリが2000ミリ秒未満で実行され、MongoDB集計クエリがほぼ9000ミリ秒、時には130Kミリ秒もかかる理由を説明できますか? PostgreSQL 9.3.2 on x86_64-apple-darwin, compiled by i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00), 64-bit PostgreSQLクエリ SELECT locomotive_id, SUM(date_trunc('second', datetime) - date_trunc('second', prevDatetime)) AS utilization_time FROM bpkdmp WHERE datetime >= '2013-7-26 00:00:00.0000' AND datetime <= '2013-7-26 23:59:59.9999' GROUP BY locomotive_id order by locomotive_id MongoDBクエリ db.bpkdmp.aggregate([ …

1
IN()パラメーターを使用したPostgreSQL PREPAREクエリ
私はPHPからクエリを準備しようとしています: pg_prepare($con, "prep", "select * from test where tid in ($1)"); 次にそれを実行します: $strpar = "3,4,6,8,10"; pg_execute($con, "prep", array($strpars)); 問題は、prepareが固定数のパラメーターを想定しているため、構築された一連の値を渡すことができないことです。パラメータを動的にする方法はありますか?

3
WindowsでPostgreSQLのマイナーアップグレードを行う方法(例:9.3.0から9.3.1)
Enterprise DBビルドのWindowsインストーラーを使用して、PostgreSQLから9.3.0から9.3.1へのマイナーアップグレードを実行するための推奨される方法は何ですか?最初にアンインストールする必要がありますか、それとも既存のインストールに上書きしてインストールしますか? 現在のインストールはpostgresql-9.3.0-1-windows-x64.exeを使用して実行されました。次に、postgresql-9.3.1-1-windows-x64.exeを使用してアップグレードします。

1
pg_activityで「トランザクション分離レベルの表示」を使用して複数のクエリを取得する
PostgreSQLサーバーを運用環境で使用しています。 次のようなクエリを実行すると select * from pg_stat_activity 私のサーバーでは、次のようなクエリの98%を取得しています SHOW TRANSACTION ISOLATION LEVEL サーバーは100接続しか受け入れないため、先に進むことができません。 なんでこんなことが起こっているの?これらのクエリをすべてブロックするにはどうすればよいですか?

4
PostgreSQLで行ごとに一意のカウンターを維持するにはどうすればよいですか?
document_revisionsテーブルに一意の(行ごとの)リビジョン番号を保持する必要があります。リビジョン番号はドキュメントにスコープが設定されているため、テーブル全体ではなく、関連するドキュメントに対してのみです。 私は最初に次のようなものを思いつきました: current_rev = SELECT MAX(rev) FROM document_revisions WHERE document_id = 123; INSERT INTO document_revisions(rev) VALUES(current_rev + 1); しかし、競合状態があります! 私はそれをpg_advisory_lockで解決しようとしていますが、ドキュメントは少し不足していて、完全に理解していません。誤って何かをロックしたくありません。 以下は許容されますか、それとも間違っていますか、それともより良い解決策がありますか? SELECT pg_advisory_lock(123); current_rev = SELECT MAX(rev) FROM document_revisions WHERE document_id = 123; INSERT INTO document_revisions(rev) VALUES(current_rev + 1); SELECT pg_advisory_unlock(123); 代わりに、特定の操作(key2)のドキュメント行(key1)をロックするべきではありませんか?だからそれは適切な解決策でしょう: SELECT pg_advisory_lock(id, 1) FROM documents WHERE id = …

1
レコードのメタデータを保存するためのベストプラクティス
個々のレコードのメタデータをデータベースに保存するためのベストプラクティスは何ですか? データベース内の多くのテーブルの作成時刻や最終更新時刻などの一般的なメタデータを保存する必要があります。私はいくつかの異なる解決策を見つけました: メタデータをテーブルに直接保存します。 長所: メタデータはレコードに直接リンクされています メタデータを取得するために結合は必要ありません 短所: 多くの重複列が必要です(継承が使用されている場合を除く) メタデータとビジネスデータは分離されていません で一般的なメタデータテーブルを作成し、ソフト外部キーを使用してデータを正しいテーブルとレコードにリンクします。 長所: 列の重複なし メタデータはビジネスデータから分離されています 短所: メタデータとデータ間の直接リンクなし(FKは使用できません) 結合には追加の条件が必要です メタデータを必要とするテーブルごとに個別のメタデータテーブルを作成します。 長所: メタデータはレコードに直接リンクされています メタデータはビジネスデータから分離されています 短所: 追加のテーブルがたくさん必要です 多くの重複列が必要です(継承が使用されている場合を除く) ここで述べたものよりも多くのオプション、長所または短所はありますか?そして、このメタデータを保存するためのベストプラクティスは何ですか?

3
反復可能読み取りの不整合
http://www.postgresql.org/docs/9.2/static/transaction-iso.html 反復可能読み取りモードは、各トランザクションがデータベースの完全に安定したビューを見ることを厳密に保証します。ただし、このビューは、必ずしも同じレベルの同時トランザクションのいくつかの(一度に1つの)逐次実行と常に整合しているとは限りません。たとえば、このレベルの読み取り専用トランザクションでも、バッチが完了したことを示すように更新された制御レコードが表示されますが、制御レコードの以前のリビジョンを読み取ったため、論理的にバッチの一部である詳細レコードの1つは表示されません。 。この分離レベルで実行されているトランザクションによってビジネスルールを適用しようとすると、競合するトランザクションをブロックする明示的なロックを注意深く使用しないと、正しく機能しない可能性があります。 これは、反復可能読み取りモードでは不可能なファントム読み取りではありませんか? ドキュメントには、反復可能な読み取りトランザクションのクエリは、トランザクションの開始時のスナップショットが表示されるとありますが、クエリが一貫性のないデータを読み取ることができるのはなぜでしょうか。

2
テーブルをキャッシュするためのフィルファクターは何ですか?
シリアル化されたJavaオブジェクトを格納するテーブルを大幅に更新/アクセスしました。これらは2〜3時間テーブルに表示され(その期間中にも更新されます)、その後削除されます。テーブルのサイズは約300MBです。私はそれが非常に、非常に頻繁にVACUUMされていることを発見しました、そしてそれを変えることfillfactorは助けになるのだろうか?

5
PostgreSQLユーザーがパスワードの変更後にサーバーに接続できない
私はこれを作成した4つの役割で満たしまし た。GUI(1)を使用してpgAdmin IIIでユーザーのパスワードを変更した後、そのユーザーはそれ以上ログインできなくなります。 pgAdmin III表示エラーメッセージ: An error has occurred: Error connecting to the server: FATAL: password authentication failed for user "sam" FATAL: password authentication failed for user "sam" 私のシステム:Ubuntu 12.04上のPostgresql 9.2 これを修正する方法はありますか? (1):アカウントpostgresでログインし、ログインロールでユーザーを右クリックし、[定義]タブに移動してパスワードを入力します

3
テーブルに数式を保存し、関数でその数式を使用する
PostgreSQL 9.1データベースがあり、その一部がエージェントの手数料を処理しています。各エージェントには、彼らが得る手数料の計算式があります。エージェントごとのコミッションを生成する機能を持っていますが、エージェント数が増えると使えなくなります。非常に長いケースステートメントと繰り返しコードを実行することを余儀なくされたため、私の機能が非常に大きくなりました。 すべての数式には定数変数があります: d ..その月に働いた日数 r ..獲得した新しいノード l ..ロイヤルティスコア s ..サブエージェント手数料 b ..基本レート i ..獲得した収益 式は次のようになります。 d*b+(l*4+r)+(i/d)+s 各エージェントは、HR部門と支払い式を交渉します。では、式をエージェントテーブルに保存して、テーブルから式を取得して値で変換し、金額を計算するだけの小さな関数のようにできますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.