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

PostgreSQLバージョン9.4

3
セッションの設定-ユーザーIDを格納するカスタム変数
ユーザーIDをカスタムセッション変数に保存し、それをトリガープロシージャで使用(読み取り)して、ユーザーアクションを承認します。私はこのようなものを見つけました: set session "myapp.user" = '12345'; ... SELECT current_setting('myapp.user'); 動作するようです-"myapp.user"は.confファイルで宣言する必要があると思いましたが、その場でセッション変数を作成できるようです(私は.confファイルをまったく変更していません)。 このようにすることの欠点はありますか?

2
Amazon RDS Postgresqlに新しい拡張機能を追加
jsonbxをRDSインスタンスにダウンロードしたい。サポートされているRDS PostgreSQLの機能には、組み込みの機能のみが表示されます。これは、機能マトリックスにない拡張機能をRDSにインストールする方法がないことを意味しますか?これの回避策はありますか?

1
部分的に構築され、停電によって終了したインデックスによって使用されたスペースを再利用する方法
Mac(10.10.4)でpostgres(postgis)9.4.2を実行しています。 私はいくつかの大きなテーブル(数TB)を持っています。 そのうちの1つで約1週間かかるインデックス作成中に、停電がバッテリーユニットとシステムよりも長く続いたときにインデックスが終了するポイントに近いと予想されるので、利用可能なHDスペースの低下を観察しました降りた。fillfactor=100静的データソースであるため、私はバッファをオフにしていて、ビルド中にそれを行いました。再起動時に、ドライブに残っている使用可能なスペースは、インデックスビルドのほぼ終了時とまったく同じです。真空分析はスペースを解放しません。 テーブルを落として再度取り込みましたが、スペースは落ちませんでした。現在、インデックスを作成するための十分なスペースがない場所にいます。 インデックスの構築中に生成されたファイルは、停電中にマシンがダウンした方法が原因でシステムによって削除できない場所でスタックしていますか? テーブルサイズとデータベース内のインデックス(そのドライブ上の唯一のデータ)を見ると、合計で約6TBです。ドライブです8TB未満、そこにある500ギガバイトは、インデックスがあったであろうという大きさです1.5TB失われたどこかに約あるようですので、ドライブに残しました。 何か案は?

2
Postgres 9.4でJSON配列要素でjson_to_recordを使用すると、「エラー:不正な形式の配列リテラル」
これは問題をうまく説明しています: 列bがテキストではなく配列である場合、次のように機能します。 select * from json_to_record('{"a":1,"b":["hello", "There"],"c":"bar"}') as x(a int, b text, d text); a | b | d ---+--------------------+--- 1 | ["hello", "There"] | しかし、b列を配列として定義すると、次のエラーが発生します。 select * from json_to_record('{"a":1,"b":["hello", "There"],"c":"bar"}') as x(a int, b text[], d text) ERROR: malformed array literal: "["hello", "There"]" DETAIL: "[" must introduce explicitly-specified array …

3
Postgresはインデックススキャンではなく順次スキャンを実行しています
約1,000万行のテーブルと日付フィールドのインデックスがあります。結果セットに26項目しかない場合でも、インデックス付きフィールドの一意の値を抽出しようとすると、Postgresは順次スキャンを実行します。オプティマイザがこの計画を選ぶのはなぜですか?そして、私はそれを避けることができますか? 他の答えから、これはインデックスと同じくらいクエリに関連していると思います。 explain select "labelDate" from pages group by "labelDate"; QUERY PLAN ----------------------------------------------------------------------- HashAggregate (cost=524616.78..524617.04 rows=26 width=4) Group Key: "labelDate" -> Seq Scan on pages (cost=0.00..499082.42 rows=10213742 width=4) (3 rows) テーブル構造: http=# \d pages Table "public.pages" Column | Type | Modifiers -----------------+------------------------+---------------------------------- pageid | integer | not null default nextval('... …

2
Postgres 9.3でのjson_object_agg()の実装
json_object_agg()Postgres 9.4 の機能が必要な気がしますが、9.3からのアップグレードは今のところできません。9.3でやりたいことを行う方法はありますか?これが私のシナリオです。click_activity次のようなデータのテーブルがあります user | offer | clicks -----|-------|-------- fred |coupons| 3 fred |cars | 1 john |coupons| 2 しかし、これを次のように変えたいと思います:(ユーザーごとのアクティビティを集計します) user | activity -----|---------- fred | {"coupons": 3, "cars": 1} john | {"coupons": 2} json_object_agg()Postgres 9.4 の機能はこれを完全に行うと思います、私が呼ばなければならないのは select user, json_object_agg(offer, clicks) from click_activity group by 1 9.3でこれを行う方法はありますか?ありがとうございました!

2
パーティション化するかしないか?
SO、外部ブログ投稿、マニュアルに関するいくつかの質問をすでに読んだことがある SO:Pgのパーティションテーブルへの外部キー制約 dba.SE:PgのパーティションテーブルへのFKのさまざまな処理方法 マニュアル:継承 マニュアル:パーティショニング 手動:制約トリガー ブログ:継承によるPostgresモデリング それでも、自分のケースを考慮してパーティション分割を行うべきかどうか疑問に思っています。 ケース-簡略化 顧客データの保存。下記の表の名前はすべて、わかりやすくするために作成されています。 顧客によって識別可能で非物理的な存在であるオブジェクト、およびオンデマンドで顧客にオブジェクトを送り返す必要がある場合にオブジェクトが実際に格納される物理オブジェクト、または他の方法でオブジェクトを処理する。それらは多対多の関係でマッピングされます。objects_nonphysical、objects_physical、objects_mapping_table。 2番目の多対多の関係は、これらの非物理オブジェクトとそのメトリックの間です。いくつかのメトリックにバインドされているオブジェクトがあります。metrics、metrics_objects_nonphysical 非物理オブジェクトと物理オブジェクトの両方に、子と親の関係である階層テーブルがあります。objects_nonphysical_hierarchy、objects_physical_hierarchy 各顧客のニーズと要件に応じて、物理オブジェクトに関するデータを提供することも、ゼロから作成する必要がある場合もあります。基本的に、私がする必要があるのは: 高速のための社内体制の維持INSERTおよびSELECTマッピングが場所を取るために起こっているのはここであるため、ステートメントを。 外部顧客が非物理オブジェクトを表示および操作できるようにシステムを維持します -データの高速検索。ステートメントの効率に対する強いニーズSELECT -このデータは、多くの顧客がいつでも検索できるようになっています。 私の配慮 データにアクセスし、データを表示して操作する顧客がいる可能性がありますが、それは、データを取得したり、データを処理している請負業者である必要はありません。 これにより、システムにテーブルパーティション分割を導入し、どのパーティションデータが該当するか(請負業者のパーティション分割)を常に把握していることを考慮し、次に、顧客のパーティション分割が必要な外部顧客向けのメインテナンスシステムに進みました。(これは、自動化ツールと一連のルールを使用して顧客の方法でデータを書き換えるのを遅らせるため、顧客ごとにテーブルごとに1つのパーティションのみをスキャンします。 データ量 特に新しい顧客のオブジェクトとメトリックをインポートする場合、私のデータは常に増加します。システムに到着する新しいデータのペースは、長期的に見て現時点では予測できません。誰が次の顧客になるかがわからない場合、実際に測定する方法はありません。現在、2つの顧客があり、各テーブルのすべての顧客に対して100万行が多かれ少なかれあります。しかし、将来的には、新規顧客の数が1,000万人になると予測しています行程度になるています。 ご質問 これらの質問はすべて互いに関連しています。 ここでパーティショニングを本当に考慮すべきですか、それとも過剰ですか?私は常に正確に1つをスキャンしているので、それは役に立つと考えていますパーティションを。 パーティショニングがFK最適な方法である場合、自分のニーズを考慮して最も効果的に制約を適用するにはどうすればよいですか?私は行くべきconstraint triggersですか、それとも内部システムのアプリケーション層に保つべきですか、それとも他の方法でしょうか? パーティショニングがうまくいかない場合、何に飛び込むべきですか? 十分なデータが提供されていない場合は、下のコメントでお知らせください。

1
SELECT DISTINCT ONサブクエリが非効率的なプランを使用しています
私はテーブルを持っていますprogresses(現在何十万ものレコードが含まれています): Column | Type | Modifiers ---------------+-----------------------------+--------------------------------------------------------- id | integer | not null default nextval('progresses_id_seq'::regclass) lesson_id | integer | user_id | integer | created_at | timestamp without time zone | deleted_at | timestamp without time zone | Indexes: "progresses_pkey" PRIMARY KEY, btree (id) "index_progresses_on_deleted_at" btree (deleted_at) "index_progresses_on_lesson_id" btree (lesson_id) "index_progresses_on_user_id" …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.