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

PostgreSQLバージョン9.3

5
json配列をpostgres配列に変換する方法は?
次のようなドキュメントdataを保持する列がありますjson。 { "name": "foo", "tags": ["foo", "bar"] } ネストされたtags配列を連結文字列(foo, bar)に変換したいと思います。それはarray_to_string()理論上の関数で簡単に可能になります。ただし、この関数はjson配列には作用しません。だから私はこのjson配列をPostgres に変える方法を疑問に思いますarrayか?

1
同じクエリで異なる条件を持つPostgresカウント
Postgres 9.3の編集 次のスキーマを持つレポートを作成しています:http : //sqlfiddle.com/#!15 / fd104/2 現在のクエリは次のように正常に機能しています。 基本的には、3テーブルの内部結合です。私はこのクエリを作成しませんでしたが、それを残した開発者がクエリを変更したいと思います。ご覧のとおり、にTotalApplication基づいてアプリケーション全体をカウントしますa.agent_id。そしてtotalapplication、結果の列を見ることができます。私が望むのは、それを削除しtotalapplicationて、新しい2列に変更することです。私はA追加したいcompletedsurveyとpartitalsurvey列を。基本的にこの部分は SELECT a.agent_id as agent_id, COUNT(a.id) as CompletedSurvey FROM forms a WHERE a.created_at >= '2015-08-01' AND a.created_at <= '2015-08-31' AND disposition = 'Completed Survey' GROUP BY a.agent_id 私はちょうど追加しましたが、唯一の違いがある同じクエリを持つAND disposition = 'Completed Survey'別の列が必要ですpartialsurveycompletedsurvey AND disposition = 'Partial Survey' そして COUNT(a.id) as PartialSurvey しかし、私はそのクエリをどこに置くか、クエリがどのように見えるかを知らないので、最終的な出力にはこれらの列があります …


2
PostgreSQLでマテリアライズドビューを段階的に更新する
PostgreSQLでマテリアライズドビューを段階的に更新することはできますか。つまり、新規または変更されたデータに対してのみですか。 次の表とマテリアライズドビューを検討してください。 CREATE TABLE graph ( xaxis integer NOT NULL, value integer NOT NULL, ); CREATE MATERIALIZED VIEW graph_avg AS SELECT xaxis, AVG(value) FROM graph GROUP BY xaxis 定期的に、新しい値が追加されるgraphか、既存の値が更新されます。graph_avg更新された値についてのみ、数時間ごとにビューを更新します。ただし、PostgreSQL 9.3では、テーブル全体が更新されます。これにはかなり時間がかかります。次のバージョン9.4ではCONCURRENT更新が可能ですが、ビュー全体が更新されます。何億行もあるため、これには数分かかります。 更新された新しい値を追跡し、部分的にのみビューを更新する良い方法は何ですか?

2
範囲タイプの正確な等価性に起因する不適切なクエリプランの処理方法
tstzrange変数の正確な等価性が必要な更新を実行しています。〜1M行が変更され、クエリには〜13分かかります。の結果はここでEXPLAIN ANALYZE見ることができ、実際の結果はクエリプランナーが推定した結果とは大きく異なります。問題は、インデックススキャンで単一の行が返されることを期待していることです。t_range これは、範囲タイプの統計が他のタイプの統計とは異なる方法で保存されるという事実に関連しているようです。pg_stats列のビューを見ると、n_distinctis -1であり、他のフィールド(most_common_valsなどmost_common_freqs)は空です。 ただし、t_rangeどこかに統計が保存されている必要があります。完全に同等ではなくt_rangeで「within」を使用する非常に類似した更新の実行には約4分かかり、実質的に異なるクエリプランを使用します(こちらを参照)。一時テーブルのすべての行と履歴テーブルのかなりの部分が使用されるため、2番目のクエリプランは理にかなっています。さらに重要なことは、クエリプランナーがのフィルタに対してほぼ正しい行数を予測することt_rangeです。 の分布t_rangeは少し珍しいです。このテーブルを使用して別のテーブルの履歴状態を保存していますが、他のテーブルへの変更は大きなダンプで一度に発生するため、の値はあまり多くありませんt_range。の一意の値のそれぞれに対応するカウントはt_range次のとおりです。 t_range | count -------------------------------------------------------------------+--------- ["2014-06-12 20:58:21.447478+00","2014-06-27 07:00:00+00") | 994676 ["2014-06-12 20:58:21.447478+00","2014-08-01 01:22:14.621887+00") | 36791 ["2014-06-27 07:00:00+00","2014-08-01 07:00:01+00") | 1000403 ["2014-06-27 07:00:00+00",infinity) | 36791 ["2014-08-01 07:00:01+00",infinity) | 999753 t_range上記のdistinctのカウントは完了しているため、カーディナリティは〜3Mです(このうち〜1Mは、いずれかの更新クエリの影響を受けます)。 クエリ1のパフォーマンスがクエリ2よりもはるかに低いのはなぜですか?私の場合、クエリ2が適切な代替品ですが、正確な範囲の均等性が本当に必要な場合、Postgresでよりスマートなクエリプランを使用するにはどうすればよいですか? インデックス付きのテーブル定義(無関係な列の削除): Column | Type | Modifiers ---------------------+-----------+------------------------------------------------------------------------------ history_id | integer | not null default nextval('gtfs_stop_times_history_history_id_seq'::regclass) …

6
ユーザーがメンバーになっているすべてのロール(継承されたロールを含む)を取得する方法は?
2つのPostgresqlデータベースグループ、「authors」と「editors」、および2人のユーザー、「maxwell」と「ernest」があるとします。 create role authors; create role editors; create user maxwell; create user ernest; grant authors to editors; --editors can do what authors can do grant editors to maxwell; --maxwell is an editor grant authors to ernest; --ernest is an author maxwellが属するロール(できればそれらのoid)のリストを返すパフォーマント関数を作成したいと思います。次のようなものです。 create or replace function get_all_roles() returns oid[] ... maxwell、authors、editorのoidを返す必要があります(ただし、ernestではありません)。 …

2
PostgreSQLがパフォーマンスSSDを最大化
テーブルごとに1億以上のエントリを持つ多くのテーブルを持つ巨大なPostgreSQL 9.3データベースを作成します。このデータベースは、基本的に読み取り専用(必要なテーブルをすべて埋めて、DBでインデックスを作成しない場合)、シングルユーザーアクセス(ローカルホストから複数のクエリを実行およびベンチマーク)されるため、DBが使用されます研究目的のみ。クエリは常に整数DBフィールドでJOINを使用します。 この目的のために、おそらくSSD(256-512GB)を購入するでしょう。DBにSSDを使用したことがないので、心配する必要はありますか?DB全体をSSDに置くことも、インデックスだけを置くこともできますか?SSD用にPostgreSQLをチューニングするために必要な特別なアドバイスやチュートリアルはありますか?i7と32GbのRAMを備えた優れたワークステーションがあることに注意してください。

2
クエリが論理的に似ている場合、なぜ計画が異なるのですか?
Seven WeeksのSeven Databasesから3日目の最初の宿題の質問に答えるために、2つの関数を作成しました。 好きな映画のタイトルや俳優の名前を入力できるストアドプロシージャを作成すると、俳優が主演した映画または類似のジャンルの映画に基づいて上位5つの候補が返されます。 私の最初の試みは正しいが、遅い。結果を返すには最大2000msかかります。 CREATE OR REPLACE FUNCTION suggest_movies(IN query text, IN result_limit integer DEFAULT 5) RETURNS TABLE(movie_id integer, title text) AS $BODY$ WITH suggestions AS ( SELECT actors.name AS entity_term, movies.movie_id AS suggestion_id, movies.title AS suggestion_title, 1 AS rank FROM actors INNER JOIN movies_actors ON (actors.actor_id = movies_actors.actor_id) …


4
トランザクション内のトランザクション
たとえば、以下のスクリプトが呼び出された場合、PostgreSQLはどのような動作を示しますか BEGIN; SELECT * FROM foo; INSERT INTO foo(name) VALUES ('bar'); BEGIN; <- The point of interest END; PostgreSQLは2番目を破棄しますか、BEGINそれともコミットが暗黙的に決定さBEGIN ENDれ、最後に別のトランザクションとしてブロックを実行しますか?

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
postgreSQLのバージョン管理ツール[終了]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新して、データベース管理者のStack Exchangeのトピックになるようにします。 5年前に閉鎖されました。 誰でもPostgreSQL用のWindowsベースのバージョン管理ツールを提案できますか。 よろしく、GP


3
WHERE条件とGROUP BYを使用したSQLクエリのインデックス
WHERE条件付きのSQLクエリに使用するインデックスと、GROUP BY現在非常に遅いインデックスを決定しようとしています。 私のクエリ: SELECT group_id FROM counter WHERE ts between timestamp '2014-03-02 00:00:00.0' and timestamp '2014-03-05 12:00:00.0' GROUP BY group_id テーブルには現在32.000.000行があります。時間枠を増やすと、クエリの実行時間が非常に長くなります。 問題のテーブルは次のようになります。 CREATE TABLE counter ( id bigserial PRIMARY KEY , ts timestamp NOT NULL , group_id bigint NOT NULL ); 現在、次のインデックスがありますが、パフォーマンスはまだ遅いです。 CREATE INDEX ts_index ON counter USING btree (ts); …

4
pg_dumpで拡張機能をスキップするにはどうすればよいですか?
これは9.3にありますが、7.x以降に発生した同様のことを覚えています。そこで、データベースを作成し、plpgsql拡張機能をインストールします。後でpg_dumpを作成し、それをデータベースに復元する前に、plpgsql拡張機能も持っていることを確認します。次に、これを復元するときに発生します: pg_restore: creating EXTENSION plpgsql pg_restore: creating COMMENT EXTENSION plpgsql pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 2053; 0 0 COMMENT EXTENSION plpgsql pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension plpgsql Command was: COMMENT ON EXTENSION plpgsql …

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