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

外部に対する次のクエリは、320万行で実行するのに約5秒かかります。 SELECT x."IncidentTypeCode", COUNT(x."IncidentTypeCode") FROM "IntterraNearRealTimeUnitReflexes300sForeign" x WHERE x."IncidentDateTime" >= '05/01/2016' GROUP BY x."IncidentTypeCode" ORDER BY 1; 通常のテーブルで同じクエリを実行すると、.6秒で戻ります。実行計画はまったく異なります。 通常のテーブル Sort (cost=226861.20..226861.21 rows=4 width=4) (actual time=646.447..646.448 rows=7 loops=1) Sort Key: "IncidentTypeCode" Sort Method: quicksort Memory: 25kB -> HashAggregate (cost=226861.12..226861.16 rows=4 width=4) (actual time=646.433..646.434 rows=7 loops=1) Group Key: "IncidentTypeCode" -> Bitmap Heap …

12 postgresql  query-performance  postgresql-9.5  postgresql-fdw 

通常の列に加えて、Postgresテーブルにはさまざまなシステム列があります。そのうちの1つはxmin、行の作成に使用されるトランザクションIDを格納します。そのデータ型はxid、ある時点で折り返す4バイトの整数です（つまり、必ずしも一意ではありません）。この関数txid_current()は、現在のトランザクションIDを返しますbigintが、「インストール中にラップしないように「エポック」カウンターで拡張されるため」として、マニュアルを引用します。 トランザクションのラップアラウンドがまだ発生していない場合、両方の値が一致しているようです： # CREATE TABLE test (label text); CREATE TABLE # INSERT INTO test VALUES ('test') RETURNING txid_current(); txid_current -------------- 674500 (1 row) INSERT 0 1 # SELECT xmin FROM test; xmin -------- 674500 (1 row) しかし、私は疑問に思う：これらの2つの値は常に同等ですか？私の知る限り、txid_current()トランザクションIDのラップアラウンド（最大2 ^ 32トランザクション）後も一意の値を配信し続けxmin、ゼロから開始します。これは、両方がその時点で異なる値を返し始めることを意味しますか？ そして、これが当てはまる場合xid、txid_current()結果を規則的に抽出xminして、テーブル内のエントリと一致するようにする方法はありますか（たとえばtxid_current()、整数へのキャスト）。 編集：トランザクションIDのラップアラウンドの後、2 ^ 32トランザクションのかなり前に起こる可能性が非常に高いことを気にかけていることを明確にします。コメントでこれを指摘してくれたDanielVéritéに感謝します。

12 postgresql  transaction  postgresql-9.5 

新しいデータベースにデータをインポートしました（約600m行のタイムスタンプ、整数、倍精度）。次に、いくつかのインデックスを作成し、いくつかの列を変更しようとしました（スペース不足の問題がありました）。データベースはバキュームされます。 pgAdmin IIIは、「一時ファイルのサイズ」が50G〜+であることを教えてくれます。 これらの一時ファイルは何ですか？これらはSQL Serverトランザクションログのようなものですか？ どうすればそれらを取り除くことができますか、データベースは必要以上に大きいようです（データベースの合計サイズは91 GBです） Windows 2012サーバーでPosgres 9.4.1を使用します。 データベース統計タブのスクリーンショット：

12 postgresql  pgadmin 

私はdonorスキーマreferenceに従ってテーブルを作成しました： CREATE TABLE reference.donor ( donor_code smallint PRIMARY KEY, donor_name character varying NOT NULL, donor_type smallint REFERENCES reference.donor_type (type_id), alpha_2_code char(2) REFERENCES reference.iso_3166_1 (alpha_2_code) ); 私はテーブルを次のように設定しました： INSERT INTO reference.donor (donor_code, donor_name, donor_type, alpha_2_code) SELECT donor_code, donor_name, donor_type, alpha_2_code FROM reference.donor_template; 実行すると： \dt+ reference.* psqlの中に私はreference.donorテーブルを見ます： List of relations Schema | Name …

12 postgresql  schema  table  psql 

2つのテーブルがある場合： CREATE TABLE foo (ts timestamp, foo text); CREATE TABLE bar (ts timestamp, bar text); 私はのための戻り値というクエリを書きたいts、fooとbarその直近の値の統一見解を表しています。つまり、foo含まれている場合： ts | foo -------- 1 | A 7 | B そしてbar含まれています： ts | bar -------- 3 | C 5 | D 9 | E 私は返すクエリが必要です： ts | foo | bar -------------- 1 | A …

12 postgresql  join  window-functions 

列a、b、c、d、e、f、g、h、i、j、kがあるテーブルでは、次のようになります。 select * from misty order by a limit 25; Time: 302.068 ms そして： select c,b,j,k,a,d,i,g,f,e,h from misty order by a limit 25; Time: 1258.451 ms 列ごとの選択をできるだけ速くする方法はありますか？ 更新： テーブルにインデックスがなく、新しく作成されたもの これはEXPLAIN ANALYZEで、あまり役に立たないようです： explain analyze select * from misty order by a limit 25; Limit (cost=43994.40..43994.46 rows=25 width=190) (actual time=404.958..404.971 rows=25 loops=1) …

12 postgresql  postgresql-9.2 

GRANT USAGE特定のデータベースのユーザー/ロールにしたい。データベースには多くのスキーマがあります。 があることは知っていますがON ALL TABLES IN SCHEMA、「すべてのスキーマ」が必要です。試しましたがGRANT USAGE .. ON DATABASE、それは明らかに間違っています（実際には存在しません）。 これはPostgres 9.3または9.4用で、AWS RDS上にあるサーバーです。

12 postgresql  postgresql-9.3  amazon-rds 

現在EC2で実行されているデータベースがあります。より大きなマシンに移動する必要があるため、RDSを使用する問題が浮上しました。 価格： 1時間あたり0.132ドルでオンデマンドで2つのSSD（各16 GB）、2つのvCPU、4 GBのメモリを備えたEC2 c3.largeインスタンスを取得できます[1]。 最も近い（価格を考慮した）RDSマシンは、db.m3.medium1時間あたり0.125ドル（シングルAZ）です[2]。このマシンには同じ量のメモリがありますが、vCPUは1つのみです[3]。さらに、ストレージとioの支払いが必要になります[2]。 したがって、これら2つの価格は非常に似ています。 EC2の利点： すでに述べたように、もう1つのvCPU。 EC2を使用する場合、2番目のディスクに先書きログを配置できます（dbに大量に書き込むときのパフォーマンスが大幅に向上します）。 EC2インスタンスでpgbouncerを実行できます（接続を開いたままにできるため、パフォーマンスが向上します）。 構成ファイルを編集できます（最終的にパフォーマンスが向上します） RDSの利点： 毎日のバックアップを自動的に行います。 RDSはEC2の利点（特に2.）をカバーできますか？他の利点はありますか？

12 postgresql  aws  amazon-ec2  amazon-rds 

あなたが持っていると仮定しましょう nodesようなテーブル。 CREATE TABLE nodes ( node serial PRIMARY KEY, parent integer NULL REFERENCES nodes(node), ts timestamp NOT NULL DEFAULT now() ); これは、最上位にルートノードがあり、ルートノードまたは他の子ノードからぶら下がっているいくつかの子ノードを持つ、標準的なノードのようなツリー構造を表します。 いくつかのサンプル値を挿入しましょう： INSERT INTO nodes (parent) VALUES (NULL), (NULL), (NULL), (NULL), (1), (1), (1), (1), (6), (1) , (6), (9), (6), (6), (3), (3), (3), (15); 次に、深さ4までの最初の10個のルートノードとそのすべての子を取得します。 WITH …

12 postgresql  order-by  cte  recursive 

テーブルがあり、fk_fc_idフィールドの値が空のすべての行を選択する必要があります（削除する前置きとして）。 Column | Type | Modifiers ---------------+-----------------------------+------------------------------------------------------------ di_timestamp | timestamp without time zone | di_item_value | character varying(10) | fk_fc_id | integer | di_id | integer | not null default nextval('data_item_di_id_seq1'::regclass) ただし、これは機能しません。 # select fk_fc_id,di_timestamp,di_item_value from data_item where fk_fc_id=""; ERROR: zero-length delimited identifier at or near """" LINE 1: ...di_timestamp,di_item_value …

12 postgresql 

CLUSTERを使用して、インデックスでテーブルを並べ替えることを検討しています。このテーブルデータの再作成により、既存のすべてのインデックスが肥大化するか、役に立たなくなることがわかります。CLUSTERの後にREINDEXが必要であるという兆候を見てきました。CLUSTER が REINDEXを行うことを示す他の参照を見つけました。公式ドキュメントは、（それがCLUSTER後にANALYZEを実行している示唆んが）REINDEXがクラスタの一部である、または必要についてのすべてでは何も言いません 誰もが明確に（つまり、公式ドキュメントへの何らかの参照を持っている）、CLUSTER後にREINDEXが必要かどうかを言うことができますか？

12 postgresql 

特定の列の連続する行の最長シーケンスを取得するPostgreSQL 9.0でクエリを作成しようとしています。 次の表を考慮してください。 lap_id (serial), lap_no (int), car_type (enum), race_id (int FK) どこlap_noがそれぞれに一意です(race_id, car_type)。 クエリで指定されたrace_idandの最長のシーケンスを生成car_typeしたいので、int最高の（または長い）を返します。 次のデータで： 1, 1, red, 1 2, 2, red, 1 3, 3, red, 1 4, 4, red, 1 5, 1, blue, 1 6, 5, red, 1 7, 2, blue, 1 8, 1, green, 1 car_type = …

12 postgresql  gaps-and-islands  window-functions  postgresql-9.0 

私はこのstackoverflowの質問に答えていて、奇妙な結果を見つけました： select * from pg_timezone_names where name = 'Europe/Berlin' ; name | abbrev | utc_offset | is_dst ---------------+--------+------------+-------- Europe/Berlin | CET | 01:00:00 | f そして次のクエリ select id, timestampwithtimezone, timestampwithtimezone at time zone 'Europe/Berlin' as berlin, timestampwithtimezone at time zone 'CET' as cet from data ; id | timestampwithtimezone | …

12 postgresql  timestamp  timezone 

私の質問には2つの部分があります。 PostgreSQLのデータベースの初期サイズを指定する方法はありますか？ 存在しない場合、データベースが時間の経過とともに大きくなった場合の断片化にどのように対処しますか？ 最近、MSSQLからPostgresに移行しました。データベースを作成するときにMSSQLの世界で行ったことの1つは、データベースとトランザクションログの初期サイズを指定することでした。これにより、特にデータベースの「通常の」サイズが事前にわかっている場合、断片化が減少し、パフォーマンスが向上します。 サイズが大きくなると、データベースのパフォーマンスが低下します。たとえば、私がそれを実行しているワークロードは通常10分かかります。データベースが大きくなると、この時間が長くなります。VACUUM、VACUUM FULL、およびVACUUM FULL ANALYZEを実行しても問題は解決しないようです。パフォーマンスの問題を解決するのは、データベースを停止し、ドライブの断片化を解消してから、VACUUM FULL ANALYZEを実行すると、テストのパフォーマンスが元の10分に戻ります。これは、断片化が痛みの原因であると疑うことにつながります。 Postgresでテーブルスペース/データベーススペースを予約するための参照を見つけることができませんでした。間違った用語を使用しているため何も見つからないか、Postgresでファイルシステムの断片化を緩和する別の方法があります。 ポインタはありますか？ ソリューション 提供された回答は、私が疑い始めたことを確認するのに役立ちました。PostgreSQLはデータベースを複数のファイルに保存します。これにより、断片化の心配なしにデータベースを拡張できます。デフォルトの動作では、これらのファイルをテーブルデータでいっぱいにパックします。これは、ほとんど変更されないテーブルには適していますが、頻繁に更新されるテーブルには適していません。 PostgreSQLはMVCCを使用して、テーブルデータへの同時アクセスを提供します。このスキームでは、更新ごとに更新された行の新しいバージョンが作成されます（これはタイムスタンプまたはバージョン番号を使用している可能性があります）。古いデータはすぐには削除されませんが、削除のマークが付けられます。実際の削除は、VACUUM操作が実行されるときに発生します。 これは曲線因子とどのように関係しますか？テーブルのデフォルトのフィルファクター100はテーブルページを完全にパックします。つまり、テーブルページ内に更新された行を保持するスペースがないことを意味します。つまり、更新された行は元の行とは異なるテーブルページに配置されます。私の経験が示すように、これはパフォーマンスに悪いです。サマリーテーブルは非常に頻繁に更新されるため（最大1500行/秒）、20のFILL FACTORを設定することを選択しました。つまり、テーブルの20％が挿入行データ用で、80％が更新データ用です。これは過度に思えるかもしれませんが、更新された行のために予約された大量のスペースは、更新された行が元のページと同じページ内に留まり、autovacuumデーモンが古い行を削除するまでにテーブルページがいっぱいにならないことを意味します。 データベースを「修正」するために、次のことを行いました。 サマリーテーブルのFILL FACTORを20に設定します。作成時にこれを行うには、パラメーターをCREATE TABLEに渡すか、ALTER TABLEを介してファクトの後に渡します。次のplpgsqlコマンドを発行しました。ALTER TABLE "my_summary_table" SET (fillfactor = 20); VACUUM FULLを発行しました。これにより、完全に新しいバージョンのテーブルファイルが書き込まれ、含意により新しいフィルファクターで新しいテーブルファイルが書き込まれます。 テストを再実行すると、数百万行のデータベースが必要な大きさであっても、パフォーマンスの低下は見られません。 TL; DR-ファイルの断片化は原因ではなく、表スペースの断片化でした。これは、特定のユースケースに合わせてテーブルのFILL FACTORを調整することで軽減されます。

12 sql-server  postgresql  fragmentation  database-size 

背景：私はhttp://sqlfiddle.com（私のサイト）に取り組んでおり、そこで悪用される可能性のある1つの手段を防止しようとしています。私が現在取り組んでいる問題について尋ねることによって、潜在的な虐待を不注意に悪化させないことを望んでいますが、あなたは何ができますか？皆さんを信頼しています。 任意のユーザーが特定のトランザクションブロック内で明示的な「コミット」呼び出しを発行することを防止したいと思います。SQL Fiddleのコンテキストから見ると、トランザクションブロックは右側のパネルで実行されるコードです。基本的に、ループしてプレーンテキストのSQLコマンドのリストを実行し、それらの変更がすべてバッチの最後に確実にロールバックされるようにします。通常、それらの変更はロールバックされますが、テキスト内に明示的な「コミット」ステートメントがある場合があるため、もちろん私のロールバックは機能しません。この明示的なコミットは、SQL Fiddleでスキーマを壊そうとするユーザーによるものである可能性が高いため、他のユーザーがエラーを確認します。 主な望ましい結果：可能であれば、JDBCレベルで明示的なコミットを無効にします。これは、複数のデータベースバックエンドベンダーをサポートする必要があるためです。もちろん、それぞれのベンダーには低レベルの癖があります。 フォールバックオプション：明示的なコミットを無効にするようにJDBCを構成できない場合、SQL Server、Oracle、MySQL、およびPostgreSQLの各バックエンドのバッチを処理中に明示的なコミットを検出するためのソリューションを利用できます。 SQL Serverの場合、このソリューションを考えました。実行する前にステートメントのXMLクエリプランを解析し、このXPathに一致するエントリの存在を確認します。 //*[@StatementType="COMMIT TRANSACTION"] これはSQL Serverでかなりうまくいくと思います。ただし、このアプローチは他のDBタイプでは機能しません。明示的なコミットに関するOracleのXML実行計画の出力は、コミットステートメントを実行しているという事実を参照していません（むしろ、コミットしているクエリから実行計画の出力を単純に繰り返します）。PostgreSQLおよびMySQLは、明示的なコミットに対して実行計画の出力（XMLまたはそれ以外）を一切提供しません。 そのため、「コミット」という単語の実際のステートメントを確認できます。これは機能しますが、可能なすべての種類のバリエーションがある場合を除きます。 declare @sql varchar(50) set @sql = 'com' + 'mit' exec(@sql); 上記はSQL Serverの例です（回避できます）が、Oracle、MySQL、PostgreSQLでも同様のことが可能だと思います。私はその仮定で間違っていますか？たぶん、彼らは「動的な」コミット文を許可しないでしょうか？Oracle、MySQL、PostgreSQLで同様のことができるかどうかを確認するために、SQL Fiddle（できればサンプルスキーマまたは他の誰かが作業している可能性のあるものではない）を自由に使用してください。そうでない場合は、単純な文字列の検出が機能する可能性があります。 さらに別の可能性 別のオプションがありました-これらのデータベースのいずれかを読み取り専用モードに設定する方法を知っている場合、そのモードでは何もコミットできませんが、それも機能します。そのモードで何もコミットできない限り、トランザクションの開始とトランザクション内でのコードの実行を許可する必要があります。それは可能ですか？ 更新 私が最近学んだこと-これは実際にはPostgreSQLの問題ではありません。トランザクションブロック内で発行されたコミットは、その同じブロックが最終的に（Postgresで）ロールバックされた場合には適用されないようです。Postgresの皆さん、ありがとう！ PhilのSO投稿へのリンクのおかげで、DEFERRABLE INITIALLY DEFERREDハックを使用してOracleを達成できると思います（コミットが発行されるとエラーがスローされますが、それを回避できます）。これはOracleに対処する必要があります。（ネストされたトランザクションがここで機能するかもしれないと少しの間考えましたが、Oracleがネストされたトランザクションをサポートしているようには見えませんか？とにかく、このように機能するものは見つかりませんでした）。 MySQLのソリューションはまだありません。ネストされたトランザクションを使用してみましたが、動作しないようです。右側のSELECT以外は許可しない、または各クエリの後にDBを削除/再作成するなど、MySQLのより抜本的なアプローチを真剣に考えています。どちらも良い音ではありません。 解決 したがって、SQL ServerとOracleについて説明したソリューションを実装しましたが、前述したように、これは実際にはPostgreSQLの問題ではありません。MySQLの場合、クエリパネルをselectステートメントのみに制限するというやや不幸なステップを踏んでいます。MySQLのDDLとDMLは、スキーマパネル（左側）で入力するだけです。これがあまりにも多くの古いフィドルを壊さないことを願っていますが、それは単にデータの一貫性を確保するために行わなければならないことだと思います。ありがとう！

12 mysql  oracle  postgresql  transaction  jdbc