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

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

3
Postgres UPDATEに39時間かかったのはなぜですか?
最大210万行のPostgresテーブルがあります。私はそれについて以下の更新を実行しました: WITH stops AS ( SELECT id, rank() OVER (ORDER BY offense_timestamp, defendant_dl, offense_street_number, offense_street_name) AS stop FROM consistent.master WHERE citing_jurisdiction=1 ) UPDATE consistent.master SET arrest_id=stops.stop FROM stops WHERE master.id = stops.id; このクエリの実行には39時間かかりました。私はこれを4(物理)コアi7 Q720ラップトッププロセッサ、大量のRAMで実行していますが、他のほとんどはほとんど実行していません。HDDスペースの制限はありません。テーブルは最近、バキュームされ、分析され、インデックスが再作成されました。 少なくとも最初のWITH完了後、クエリが実行されている間は常に、CPU使用率は通常低く、HDDは100%使用されていました。HDDが非常に激しく使用されていたため、他のアプリの実行速度は通常よりもかなり遅くなりました。 ラップトップの電源設定は高パフォーマンス(Windows 7 x64)でした。 ここに説明があります: Update on master (cost=822243.22..1021456.89 rows=2060910 width=312) CTE stops -> WindowAgg (cost=529826.95..581349.70 …
17 postgresql 


2
pg_restore:[アーカイバ(db)]クエリを実行できませんでした:エラー:スキーマ "public"は既に存在します
pg_dump / pg_restoreを使用してPostgreSQLデータベースをバックアップおよび復元していますが、pg_restoreからいくつかのエラーメッセージ(およびゼロ以外の終了ステータス)を取得しています。私は非常にシンプルなベースケース(以下に概説)を試しましたが、まだこれらのエラーが発生しました: pg_restore:[アーカイバ(db)] TOC処理中のエラー: pg_restore:[archiver(db)] TOCエントリ5からのエラー。2615 2200 SCHEMAパブリックポストグレス pg_restore:[アーカイバ(db)]クエリを実行できませんでした:エラー:スキーマ "public"は既に存在します コマンドは:CREATE SCHEMA public; 再現する手順: 新鮮なバニラUbuntu 14.04ディストリビューションをインストールします(このVagrantボックスで Vagrantを使用しています)。 PostgreSQL 9.3をインストールし、LinuxユーザーからのPostgreSQLユーザー「postgres」としてローカル接続を許可するように設定します。 テストデータベースを作成します。私はただやっている: vagrant @ vagrant-ubuntu-trusty-64:〜$ psql --username = postgres postgres psql(9.3.5) ヘルプを表示するには「help」と入力します。 postgres =#データベースmydbを作成; データベース作成 postgres =#\ q vagrant @ vagrant-ubuntu-trusty-64:〜$ psql --username = postgres mydb psql(9.3.5) ヘルプを表示するには「help」と入力します。 mydb =#create table …

7
postgresqlデータベースを監視するための優れたツールはありますか[非公開]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新して、データベース管理者のStack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 すぐに、非常に負荷の高いpostgresqlデータベースをいくつか用意する予定です。mysqlデータベースを高負荷で管理しているのですが、今はpostgresqlを使用する必要があります。 日々のデータベース管理とステータスレポートに最適なツールを教えてください。(もちろんコンソールは最高のものですが、他のオプションについても知りたいです) すべての経験は大歓迎です!

1
PostgreSQLはオブジェクトパーミッションをどの順序でチェックしますか?
データベースロール、、ストアドプロシージャとして定義されたuser1関数、something()および次のように作成されたビューを指定します。 CREATE VIEW view1 AS select * from something() そして、この許可が与えられた場合: REVOKE ALL ON FUNCTION something FROM user1 REVOKE SELECT ON view1 FROM user1 実行するSELECT * FROM view1と、エラーが発生しますpermission denied for function something()。 私の質問は、ビューの選択権限を取り消すと、なぜ関数が呼び出されるのですか?私は次のようなものを受け取ることを期待していました: permission denied for relation view1 ありがとうございました!

1
PostgreSQLの(x IS NOT NULL)vs(NOT x IS NULL)
なぜx IS NOT NULL等しくないのNOT x IS NULLですか? このコード: CREATE TABLE bug_test ( id int, name text ); INSERT INTO bug_test VALUES (1, NULL); DO $$ DECLARE v_bug_test bug_test; BEGIN RAISE NOTICE '%: %', v_bug_test, (v_bug_test IS NULL); RAISE NOTICE '%: %', v_bug_test, (v_bug_test IS NOT NULL); RAISE NOTICE '%: %', …
16 postgresql  null 

2
CREATE TABLE ASとSELECT INTO
PostgreSQLのサポートCREATE TABLE ASとSELECT INTOするとき、私は両方使うのですか? CREATE TABLE AS -クエリの結果から新しいテーブルを定義する CREATE TABLE ASテーブルを作成し、SELECTコマンドで計算されたデータでテーブルを埋めます。表の列には、の出力列に関連付けられた名前とデータ型SELECTがあります(ただし、新しい列名の明示的なリストを指定することで列名をオーバーライドできます)。 CREATE TABLE ASビューの作成と似ていますが、実際にはまったく異なります。新しいテーブルを作成し、クエリを一度だけ評価して、新しいテーブルに最初に入力します。新しいテーブルは、クエリのソーステーブルに対するその後の変更を追跡しません。対照的に、ビューSELECTは、クエリが実行されるたびに定義ステートメントを再評価します。 その後。 SELECT INTO -クエリの結果から新しいテーブルを定義する SELECT INTO新しいテーブルを作成し、クエリによって計算されたデータをそのテーブルに入力します。通常ののように、データはクライアントに返されませんSELECT。新しいテーブルの列には、の出力列に関連付けられた名前とデータ型がありSELECTます。
16 postgresql  ctas 

2
非整数の主キーに関する考慮事項
環境 分散アプリケーションからのデータを保存するデータベース(PostgreSQL 9.6)を設計しています。アプリケーションの分散された性質のSERIALため、潜在的な競合状態のため、自動インクリメント整数()を主キーとして使用することはできません。 自然な解決策は、UUID、またはグローバルに一意の識別子を使用することです。Postgresには組み込みのUUIDtypeが付属しており、これがぴったりです。 私がUUIDで抱えている問題は、デバッグに関連しています。それは人間に優しい文字列です。識別子ff53e96d-5fd7-4450-bc99-111b91875ec5は何も教えてくれませんが、ACC-f8kJd9xKCdが一意であるとは限りませんが、ACCオブジェクトを扱っていることを教えてくれます。 プログラミングの観点からは、いくつかの異なるオブジェクトに関連するアプリケーションクエリをデバッグするのが一般的です。プログラマーACCがORD(order)テーブルで(account)オブジェクトを誤って検索するとします。人間が読み取れる識別子を使用して、プログラマーは問題を即座に特定しますが、UUIDを使用して、何が問題なのかを理解するのに少し時間を費やします。 UUIDの「保証された」一意性は必要ありません。私はない、競合なしで鍵を生成するためのいくつかの部屋を必要とするが、UUIDは過剰です。また、最悪のシナリオでは、衝突が発生した場合、世界の終わりにはなりません(データベースがそれを拒否し、アプリケーションが回復できます)。したがって、トレードオフを考慮して、より小さくても人間に優しい識別子が私のユースケースにとって理想的なソリューションになるでしょう。 アプリケーションオブジェクトの特定 私が思いついた識別子の形式は次のとおりです。{domain}-{string}ここ{domain}で、はオブジェクトドメイン(アカウント、注文、製品)に置き換えられ{string}、ランダムに生成された文字列です。場合によっては{sub-domain}、ランダムな文字列の前にaを挿入することも理にかなっています。レッツは、の長さを無視{domain}し、{string}一意性を保証する目的のために。 インデックス作成/クエリのパフォーマンスに役立つ場合、形式のサイズを固定できます。 問題 知っています: のような形式の主キーが必要ですACC-f8kJd9xKCd。 これらの主キーは、いくつかのテーブルの一部になります。 これらすべてのキーは、6NFデータベースのいくつかの結合/関係で使用されます。 ほとんどのテーブルのサイズは、中規模から大規模(平均で最大100万行、最大で最大1億行)です。 パフォーマンスに関して、このキーを保存する最良の方法は何ですか? 以下に4つの解決策を示しますが、データベースに関する経験が少ないため、どれが最適かはわかりません。 考慮された解決策 1.文字列として保存(VARCHAR) (Postgresはの間に違いはありませんCHAR(n)とVARCHAR(n)、私は無視していますCHAR)。 いくつかの調査の後VARCHAR、特に結合操作での文字列比較は、を使用するよりも遅いことがわかりましたINTEGER。これは理にかなっていますが、この規模で心配する必要があるのでしょうか? 2.バイナリとして保存(bytea) Postgresとは異なり、MySQLにはネイティブUUIDタイプがありません。BINARY36 バイトのフィールドではなく、16バイトのフィールドを使用してUUIDを保存する方法を説明する投稿がいくつかありますVARCHAR。これらの投稿は、キーをバイナリとして保存するというアイデアを与えてくれました(byteaPostgresで)。 これによりサイズを節約できますが、パフォーマンスに関心があります。どの比較が高速であるかについての説明、つまりバイナリまたは文字列の説明を見つけることができなかった。バイナリ比較の方が速いと思います。もしそうであれば、プログラマは毎回データをエンコード/デコードする必要がありbyteaますがVARCHAR、おそらくの場合よりも優れています。 私は間違っているかもしれないが、私は両方だと思うbyteaとVARCHAR、バイト(または文字単位)による(平等)のバイトを比較します。この段階的な比較を「スキップ」し、単に「全体」を比較する方法はありますか?(私はそうは思いませんが、チェックの費用はかかりません)。 として保存するのbyteaが最善の解決策だと思いますが、私が無視している他の選択肢があるのではないかと思います。また、ソリューション1で述べたのと同じ懸念が当てはまります。比較のオーバーヘッドは心配するほど十分ですか? 「クリエイティブ」ソリューション 動作する2つの非常に「創造的な」ソリューションを思い付きました。どの程度であるかわかりません(つまり、テーブル内で数千行以上にスケーリングするのが難しい場合)。 3. UUID「ラベル」を付けて保存する UUIDを使用しない主な理由は、プログラマーがアプリケーションをよりよくデバッグできるようにするためです。しかし、両方を使用できる場合:データベースはすべてのキーをUUIDs としてのみ格納しますが、クエリが実行される前/後にオブジェクトをラップします。 たとえば、プログラマはを要求しACC-{UUID}、データベースはそのACC-部分を無視し、結果を取得して、すべてをとして返します{domain}-{UUID}。 おそらく、ストアドプロシージャまたは関数を使用したハッカーでこれが可能になるかもしれませんが、いくつかの質問が思い浮かびます。 これ(各クエリでドメインを削除/追加する)はかなりのオーバーヘッドですか? これも可能ですか? ストアドプロシージャや関数を使用したことがないため、これが可能かどうかもわかりません。誰かが光を当てることはできますか?プログラマと保存されたデータの間に透明なレイヤーを追加できれば、それは完璧なソリューションのようです。 4.(私のお気に入り)IPv6として保存 cidr はい、あなたはそれを正しく読みました。IPv6アドレス形式は私の問題を完全に解決することがわかりました。 最初の数オクテットでドメインとサブドメインを追加し、残りをランダム文字列として使用できます。 衝突確率は OKです。(ただし、2 ^ 128は使用しませんが、それでも大丈夫です。) 等値比較は(できれば)最適化されているため、単にを使用するよりもパフォーマンスが向上する可能性がありますbytea。 containsドメインとその階層がどのように表されるかに応じて、実際にいくつかの興味深い比較を実行できます。 たとえば0000、ドメイン「製品」を表すためにコードを使用するとします。キー0000:0db8:85a3:0000:0000:8a2e:0370:7334は製品を表します0db8:85a3:0000:0000:8a2e:0370:7334。 …

1
Postgresの0001年のタイムゾーンに、UTCからのこのようなクレイジーなオフセットがあるのはなぜですか?
Postgres 9.5では、年0001(ゼロ0000年なし)を試しているときに以下の結果が表示されたことに驚きました。 のオフセット-07:52:58? いくつかのサンプルコード。Iの混合使用することを注意TIMESTAMP WITH TIME ZONEしてTIMESTAMP WITHOUT TIME ZONE、慎重に読んでください。 SET TIME ZONE 'America/Los_Angeles' ; SELECT (TIMESTAMP WITH TIME ZONE '2015-01-01 00:00:00.0', TIMESTAMP WITH TIME ZONE '0001-01-01 00:00:00.0Z', TIMESTAMP WITHOUT TIME ZONE '0001-01-01 00:00:00.0Z') ; ("2015-01-01 00:00:00-08","0001-12-31 16:07:02-07:52:58 BC","0001-01-01 00:00:00") 私はその2番目の値に驚いています0001-12-31 16:07:02-07:52:58 BC。America/Los_AngelesUTCから8時間遅れているのと同じように、オフセットを8時間戻し-08:00ます。しかし-08:00、オフセットの代わりにです-07:52:58。どうして? UTCで問題なし UTCでデータを入力する場合、このような問題はありません。 SET TIME ZONE 'UTC' ; …

2
検索文字列が長くなると、トライグラム検索が非常に遅くなります
Postgres 9.1データベースには、table1約150万行と1列のテーブルがありますlabel(この質問のために簡略化された名前)。 機能的なtrigram-indexがありますlower(unaccent(label))(インデックスでunaccent()使用できるように不変にされています)。 次のクエリは非常に高速です。 SELECT count(*) FROM table1 WHERE (lower(unaccent(label)) like lower(unaccent('%someword%'))); count ------- 1 (1 row) Time: 394,295 ms ただし、次のクエリは遅くなります。 SELECT count(*) FROM table1 WHERE (lower(unaccent(label)) like lower(unaccent('%someword and some more%'))); count ------- 1 (1 row) Time: 1405,749 ms また、検索がより厳密であっても、単語の追加はさらに遅くなります。 私は最初の単語のサブクエリを実行し、次に完全な検索文字列でクエリを実行する簡単なトリックを試しましたが、クエリプランナは(悲しいことに)私の陰謀を見ました: EXPLAIN ANALYZE SELECT * FROM ( SELECT id, …

1
関数パラメーターとUSING句を使用したJOINの結果との名前の競合
現在のPostgres 9.4でのこのセットアップを考えると(この関連する質問から): CREATE TABLE foo (ts, foo) AS VALUES (1, 'A') -- int, text , (7, 'B'); CREATE TABLE bar (ts, bar) AS VALUES (3, 'C') , (5, 'D') , (9, 'E'); 前の質問からのSQL Fiddleもあります。 私が書いたSELECTとをFULL JOIN参照し、質問の目的を達成するために。簡略化: SELECT ts, f.foo, b.bar FROM foo f FULL JOIN bar b USING (ts); 仕様に従って、列をアドレス指定する正しい方法tsは、テーブル修飾なしです。入力値(f.tsまたはb.ts)のいずれかをNULLにすることができます。このUSING句は、奇妙なケースを少し作成します。実際には入力に存在しない「入力」列を導入します。これまでのところとてもエレガント。 …

1
リモートのpostgresqlデータベースに接続できません
リモートpsqlデータベースに接続しようとしています。pg_hba.confエントリにクライアントのIPアドレスを追加する前に、エラーメッセージが表示されました。 xdev@xdevbox:~$ psql -U postgres testdb -h 10.1.1.47 psql: FATAL: no pg_hba.conf entry for host "10.201.50.71", user "postgres", database "testdb", SSL off クライアントのIPに信頼設定を追加しました。また、サーバー上のpostgres.confのリッスンアドレスを変更して、「*」をリッスンしました。次に、/ etc / init.d / postgresql restartコマンドを使用してデータベースサーバーを再起動しました。 接続しようとすると、次のエラーメッセージが表示されます。 psql: could not connect to server: Connection refused Is the server running on host "10.1.1.47" and accepting TCP/IP connections on …

1
PostgreSQLのGEQO(遺伝子クエリ最適化)の変更
PostgreSQLのGEQO機能に沿った機能を実装する必要があります。GEQOのアプローチはクエリプランを整数文字列としてエンコードすることであり、GEQOはこれらの可能な結合シーケンスをランダムに生成することを理解しています。ソース:http : //www.postgresql.org/docs/9.3/static/geqo-pg-intro.html 私の質問:正しい結合シーケンスを明確に知っている場合にGEQO関数を変更し、異なる結合シーケンスを検索する必要がないようにする方法。たとえば、4つの関係を結合する最適な方法が4-1-3-2であることがわかっていれば、他の順列をチェックする必要はありません。 GEQOがPostgreSQLにどのように実装されているかについての良い資料はありません。PostgreSQLはGEQO機能の全体像のみを提供しますが、あまり説明しません。 または、GEQOを使用せずにstandard_join_search()自体でこの機能を実現できますか?

1
ctidをページ番号と行番号に分解するにはどうすればよいですか?
テーブルの各行には、行の物理的な場所を表すタイプのシステム列が ctidありますtid。 create table t(id serial); insert into t default values; insert into t default values; select ctid , id from t; ctid | id :---- | -: (0,1)| 1 (0,2)| 2 ここに dbfiddle ctid最も適切なタイプ(例えばinteger、bigintまたはnumeric(1000,0))からページ番号だけを取得する最良の方法は何ですか? 私は考えることができる唯一の方法は非常に醜いです。

3
PostgreSQL(または一般的なSQL)にビジネスロジックのアクセス許可を実装する方法は?
アイテムのテーブルがあると仮定しましょう: CREATE TABLE items ( item serial PRIMARY KEY, ... ); 次に、各アイテムの「アクセス許可」の概念を紹介します(ここでは、データベースアクセス許可についてではなく、そのアイテムのビジネスロジック許可について説明していることに注意してください)。各アイテムにはデフォルトの許可があり、デフォルトの許可よりも優先されるユーザーごとの許可もあります。 私はこれを実装するいくつかの方法を考えて、次の解決策を考え出しましたが、どれが最良であり、なぜかについてはわかりません。 1)ブール解 各権限にブール列を使用します。 CREATE TABLE items ( item serial PRIMARY KEY, can_change_description boolean NOT NULL, can_change_price boolean NOT NULL, can_delete_item_from_store boolean NOT NULL, ... ); CREATE TABLE item_per_user_permissions ( item int NOT NULL REFERENCES items(item), user int NOT …
16 postgresql  enum 

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