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

3列（A、B、Dなど）のテーブルがあり、新しい列を導入しなければならなかった場合、Dの現在の位置を置き換えるためにCと言います。次の方法を使用します。 CおよびD2として2つの新しい列を導入します。 Dの内容をD2にコピーします。 Dを削除します D2の名前をDに変更します。 新しい順序は、A、B、C、およびDです。 （これまでのところ）問題が発生しなかったため、これは正当な慣行だと思いました。 しかし、今日、同じテーブルでステートメントを実行する関数が次のエラーを返したときに問題に遭遇しました。 table row type and query-specified row type do not match そして次の詳細： Query provides a value for a dropped column at ordinal position 13 私はPostgreSQLを再起動して、こことここでVACUUM FULL提案されているように最後に関数を削除して再作成しようとしましたが、これらの解決策は機能しませんでした（システムテーブルが変更された状況に取り組むことを除いて）。 非常に小さなデータベースで作業する余裕があったので、エクスポートし、削除してから再インポートしました。これにより、機能に関する問題が修正されました。 ここに見られるように、システムテーブルを変更する（pg_attributeなどで手を汚す）ことによって、列の自然な順序をいじってはならないという事実を知っていました。 Postgresの列の自然な順序を変更することは可能ですか？ 私の関数によってスローされたエラーから判断すると、私のメソッドで列の順序をシフトすることもまたノーであることがわかりました。誰が私がやっていることも間違っている理由についていくつかの光を当てることができますか？ Postgresバージョンは9.6.0です。 関数は次のとおりです。 CREATE OR REPLACE FUNCTION "public"."__post_users" ("facebookid" text, "useremail" text, "username" text) …

15 postgresql  functions  metadata  database-internals  postgresql-9.6 

これが私の実世界の問題の最小限の例です： create table t(id serial primary key, rnd double precision); もちろん、挿入した列をreturning句で返すことができます： with w as (insert into t(rnd) values(random()) returning *) insert into t(rnd) select random() from w returning *; /* | ID | RND | |----|----------------| | 9 | 0.203221440315 | */ リテラルを返すこともできます： with w as (insert into t(rnd) values(random()) …

14 postgresql  postgresql-9.6 

いくつかの仮定をしてみましょう。 次のような表があります。 a | b ---+--- a | -1 a | 17 ... a | 21 c | 17 c | -3 ... c | 22 私のセットに関する事実： テーブル全体のサイズは〜10 10行です。 私は値で〜100kの行を持ってa列内のa他の値（例えばについても同様、c）。 これは、列 'a'に〜100k個の異なる値があることを意味します。 私のクエリのほとんどは、aの特定の値のすべてまたはほとんどの値を読み取りますselect sum(b) from t where a = 'c'。 テーブルは、連続した値が物理的に近くなるように記述されます（順番に記述されているかCLUSTER、そのテーブルと列で使用されていると仮定しますa）。 テーブルが更新されることはめったにありません。読み取り速度のみが重要です。 テーブルは比較的狭い（タプルごとに〜25バイト、+ 23バイトのオーバーヘッドなど）。 問題は、どのようなインデックスを使用する必要があるかということです。私の理解は： BTreeここでの私の問題は、BTreeインデックスが重複する値を格納することを知っている限り、巨大になることです（テーブルが物理的にソートされていると想定できないため、必要です）。BTreeが巨大な場合、インデックスとインデックスが指すテーブルの部分の両方を読み取る必要があります。（fillfactor = 100インデックスのサイズを少し小さくするために使用できます。） BRIN私の理解では、役に立たないページを読むことを犠牲にして、ここに小さなインデックスを作成できるということです。小さな値を使用pages_per_rangeすると、インデックスが大きくなり（インデックス全体を読み取る必要があるためBRINで問題になります）、大きな値を使用pages_per_rangeすると、多くの無駄なページを読み取ることになります。pages_per_rangeそれらのトレードオフを考慮に入れた優れた価値を見つけるための魔法の公式はありますか？ GIN …

14 postgresql  index  query-performance  clustered-index  postgresql-9.6 

PostgreSQLのドキュメントでは、整数データ型は2バイト、4バイト、または8バイトのスペースに格納できると言われています。データベース内のテーブルの列の1つに1バイトの整数値が含まれていて、それを1バイトのデータ型で格納したい。 PostgreSQLで1バイト整数データ型を使用する拡張機能または方法はありますか？ NUMERIC（1,0）は何バイトですか？

14 datatypes  storage  postgresql-9.6 

PostgreSQL 9.6のクエリ計画に問題があります。私のクエリは次のようになります： SET role plain_user; SELECT properties.* FROM properties JOIN entries_properties ON properties.id = entries_properties.property_id JOIN structures ON structures.id = entries_properties.entry_id WHERE structures."STRUKTURBERICHT" != '' AND properties."COMPOSITION" LIKE 'Mo%' AND ( properties."NAME" LIKE '%VASP-ase-preopt%' OR properties."CALCULATOR_ID" IN (7,22,25) ) AND properties."TYPE_ID" IN (6) 上記で使用したテーブルに対して行レベルのセキュリティを有効にしています。 を使用するset enable_nestloop = Trueと、クエリプランナーはネストループを実行し、合計実行時間は約37秒になります。https：//explain.depesz.com/s/59BR をset enable_nestloop …

13 postgresql  query-performance  join  postgresql-9.6  row-level-security 

station_logsPostgreSQL 9.6データベースにテーブルがあります。 Column | Type | ---------------+-----------------------------+ id | bigint | bigserial station_id | integer | not null submitted_at | timestamp without time zone | level_sensor | double precision | Indexes: "station_logs_pkey" PRIMARY KEY, btree (id) "uniq_sid_sat" UNIQUE CONSTRAINT, btree (station_id, submitted_at) それぞれlevel_sensorについてsubmitted_at、に基づいて最後の値を取得しようとしていますstation_id。固有のstation_id値は約400 個、1日あたり約20,000行station_idです。 インデックスを作成する前に： EXPLAIN ANALYZE SELECT DISTINCT ON(station_id) …

13 postgresql  query-performance  greatest-n-per-group  postgresql-9.6 

シンプルなDB構造（オンラインフォーラム用）： CREATE TABLE users ( id integer NOT NULL PRIMARY KEY, username text ); CREATE INDEX ON users (username); CREATE TABLE posts ( id integer NOT NULL PRIMARY KEY, thread_id integer NOT NULL REFERENCES threads (id), user_id integer NOT NULL REFERENCES users (id), date timestamp without time zone NOT NULL, …

12 postgresql  query-performance  postgresql-9.6 

次のような分割テーブル構造があります。 CREATE TABLE measurements ( sensor_id bigint, tx timestamp, measurement int ); CREATE TABLE measurements_201201( CHECK (tx >= '2012-01-01 00:00:00'::timestamp without time zone AND tx < ('2012-01-01 00:00:00'::timestamp without time zone + '1 mon'::interval)) )INHERITS (measurements); CREATE INDEX ON measurements_201201(sensor_id); CREATE INDEX ON measurements_201201(tx); CREATE INDEX ON measurements_201201(sensor_id, tx); .... …

11 postgresql  partitioning  query-performance  postgresql-9.6 

2つのpg_trgmインデックスをテーブルに追加しました。これは、ユーザー名、またはサインアップ中にスペルが間違っているメールアドレス（ "@ gmail.con"など）でユーザーを検索する必要があるため、メールアドレスまたは名前によるあいまい検索を可能にします。ANALYZEインデックスの作成後に実行されました。 ただし、これらのインデックスのいずれかでランク付けされた検索を実行すると、ほとんどの場合非常に遅くなります。つまり、タイムアウトを長くすると、クエリが 60秒で返される場合がありますが、15秒という非常にまれな場合もありますが、通常はクエリがタイムアウトします。 pg_trgm.similarity_threshold0.3はのデフォルト値ですが、これを上げて0.8も違いはないようです。 この特定のテーブルには2,500万行以上があり、常に照会、更新、および挿入されます（それぞれの平均時間は2ミリ秒未満です）。セットアップは、汎用SSDストレージと多かれ少なかれデフォルトのパラメーターを備えたRDS db.m4.largeインスタンスで実行されているPostgreSQL 9.6.6です。pg_trgm拡張子はバージョン1.3です。 クエリ： SELECT * FROM users WHERE email % 'chris@example.com' ORDER BY email <-> 'chris@example.com' LIMIT 10; SELECT * FROM users WHERE (first_name || ' ' || last_name) % 'chris orr' ORDER BY (first_name || ' ' || last_name) <-> 'chris orr' …

9 postgresql  query-performance  postgresql-performance  postgresql-9.6 

PostgreSQL 9.2では、地理（postGIS）タイプと整数の両方を複合インデックスとして持つインデックスを問題なく作成できました。しかし、現在（9.6）はインデックスの作成に不満を示しており、それが提供するヒントを理解できません。 列とデータはすべて適切に作成されていますが、Postgresは作成インデックスについて不平を言っています。 ERROR: data type integer has no default operator class for access method "gist" HINT: You must specify an operator class for the index or define a default operator class for the data type. ********** Error********** ERROR: data type integer has no default operator class for access method …

8 postgresql  postgis  postgresql-9.6