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

クラスター内のロールはどこに保存されますか、どのようにダンプしますか？ dbのpg_dumpを実行し、それを別のクラスターにロードしましたが、これらのエラーがたくさん発生します。 psql:mydump.sql:3621: ERROR: role "myrole" does not exist だから明らかに私のデータベースのダンプにはロールが含まれていません。「postgres」データベースをダンプしようとしましたが、役割も表示されません。 使用する必要がありますpg_dumpall --roles-onlyか？ Postgresqlバージョン8.4.8および9.1.4 OS：Ubuntu 11.04 Natty

27 postgresql  restore  dump  role 

サーバー上のhdスペースの90％近くを占めるテーブルが1つあります。スペースを空けるために、いくつかの列をドロップすることにしました。しかし、スペースをOSに戻す必要があります。ただし、問題は、VACUUM FULLを実行し、テーブルのコピーを作成するための十分な空き領域がない場合にどうなるかわからないことです。 VACUUM FULLは使用すべきではないことを理解していますが、このシナリオでは最良の選択肢であると考えました。 任意のアイデアをいただければ幸いです。 PostgreSQL 9.0.6を使用しています

27 postgresql  delete  alter-table  database-size  vacuum 

ジョブの役割を含むテーブルがあるとします： CREATE TABLE roles ( "role" character varying(80) NOT NULL, CONSTRAINT "role" PRIMARY KEY (role) ); さらにテーブル、ユーザーがあり、各行（特定のユーザー）が任意の数のジョブロールを持つことができるとします。 CREATE TABLE users ( username character varying(12) NOT NULL, roles character varying(80)[] NOT NULL, CONSTRAINT username PRIMARY KEY (username) ); の各メンバーがusers.roles[]roles.role に存在することを確認する必要があります。私が望むのは、users.roles[]ifがroles.roleを参照するような各メンバーの外部キー制約だと思われます。 これはpostgresでは不可能のようです。私はこれを間違った方法で見ていますか？これを処理するための推奨される「正しい」方法は何ですか？

27 postgresql  referential-integrity  array 

この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 PostgreSQL 9.0.8にはオブジェクトの大きなテーブル（1500万行以上）があり、そのために古いフィールドをクエリしたいと思います。 スケーラビリティと同時実行性を目的として、クエリを数百万で除算し、数日前の日付のupdated_atフィールドを使用してすべてのデータをフェッチしたい。 100万のIDで多くのインデックスとクエリを試しましたが、HerokuのRoninハードウェアで100秒未満のパフォーマンスを得ることができないようです。 これを可能な限り効率的にしようとしていない提案を探しています。 TRY＃1 EXPLAIN ANALYZE SELECT count(*) FROM objects WHERE (date(updated_at)) < (date(now())-7) AND id >= 5000001 AND id < 6000001; INDEX USED: (date(updated_at),id) 268578.934 ms TRY＃2 EXPLAIN ANALYZE SELECT count(*) FROM objects WHERE ((date(now()) - (date(updated_at)) > 7)) AND id >= …

27 postgresql  performance  index  partitioning  postgresql-performance 

psqlデータベーススキーマを設定するための単一のトランザクションとして、複数のSQLスクリプトを順番に実行したいと思います。これを行う最良の方法は何ですか？過去にpsql、他のファイルを含むマスタースクリプトを実行したことがありますが、このスクリプトの構文は覚えていません。

27 postgresql  psql 

私は現在、新しいプロジェクトを手に入れたため、PostgreSQLとMySQLの違いを学んでいます。また、既存のソフトウェアをMySQLからPostgreSQLに移行するつもりです。私は実際に2つのコマンド（ユーザー/データベース/コマンドプロンプトなど）を比較してHTMLテーブルを作成し始めました。ここで答えを読んだ後role、グループとして使用されているように見えることに気付きました。MySQLので、私は二人のユーザ、基本的にパブリック（持ってDELETE、INSERT、SELECTおよびUPDATEアクセス権）と夫婦追加の権限を持つ管理者ユーザーを。 したがって、基本的にWindows 7コマンドプロンプト（ローカル開発のみ）で... ロールは、ユーザー、グループ、またはPostgreSQL固有の緩やかに使用される用語ですか？ データベース内のすべてのテーブルに対して、特定のユーザーに特定の権限のみを付与するにはどうすればよいですか？ データベース内のすべてのテーブルに対して、特定のユーザーにすべての権限を付与するにはどうすればよいですか？ ユーザー権限を使用する場合、GRANTまたは使用する場合、ロールはユーザーと比較してREVOKEどうですか？

27 postgresql  users 

DebianでPostgres 9.4.4を実行していますが、次のようORDER BYな動作になります。 veure_test=# show LC_COLLATE; lc_collate ------------- en_US.UTF-8 (1 row) veure_test=# SELECT regexp_split_to_table('D d a A c b CD Capacitor', ' ') ORDER BY 1; regexp_split_to_table ----------------------- a A b c Capacitor CD d D (8 rows) そしてuname -a： Linux ---- 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1 x86_64 GNU/Linux しかし、Postgres …

27 postgresql  collation 

私はPostgreSQLが初めてであり、データベース全般については多少新しいです。PostgresでUUID値をインデックスする方法の確立された方法はありますか？ハッシュを使用するかトライを使用するかは、自動的に使用する組み込みのものが既に存在しない限り、分割されます。私が使用するものはすべて、膨大な量のデータを処理します。 SP-GiST演算子ファミリ「text_ops」は、トライを使用してインデックスを作成します。UUIDは非常に長く、非常に異なるため、完全一致検索のみを行う場合でも、これらのサウンドは魅力的です。 ハッシュオプションもあります。ハッシュはO（1）であり、もちろん平等以外の比較を行う必要はありませんが、UUIDは非常に長いため、ハッシュからハッシュを生成すると多くの時間が浪費されるのではないかと心配しています。 または、これはシステムに依存しすぎて、仕様を使用するものですか？ ほとんどの場合、bigserialを使用したいのですが、これにはuuidを使用するように言われました。異なるデータベースを使用する複数のサーバーが存在する可能性があるため、uuidが必要です。したがって、一意のbigintがあることを保証するものではありません。サーバーごとに異なるシーケンス（およびシード）を使用できますが、それでもUUIDほど柔軟ではありません。たとえば、IDとその参照をどこでも変換しないと、データベースエントリをあるサーバーから別のサーバーに移行することはできません。

26 postgresql  index  uuid 

PostgreSQL（9.4）データベースを使用してRuby on Railsでアプリケーションを開発しています。私のユースケースでは、アプリケーションの全体のポイントはモデル上の非常に特定の属性を検索するため、テーブルの列は非常に頻繁に検索されます。 私は現在、使用するかどうかを決定していますintegerタイプを、または単に（例えば、一般的な文字列型を使用character varying(255)、Railsのではデフォルトである私は、性能差がインデックスにどうなるかわからないよう、列に対して）。 これらの列は列挙型です。可能な値の量に対して固定サイズがあります。ほとんどの列挙の長さは5を超えません。これは、アプリケーションの存続期間中、インデックスが多少固定されることを意味します。したがって、整数と文字列のインデックスはノードの数が同じになります。 ただし、インデックス付けされる文字列の長さは約20文字で、メモリ内では整数の約5倍になります（整数が4バイトで、文字列が1文字あたり1バイトの純粋なASCIIの場合、これは成り立ちます）。私は、データベースエンジンがインデックスのルックアップを行う方法を知りませんが、それが一致するまで、それは「スキャン」の文字列に必要がある場合は、正確にそして本質的には、手段は、文字列検索が遅くなる整数のルックアップよりも5倍になるということ。整数ルックアップに一致するまでの「スキャン」は20ではなく4バイトになります。これが私が想像していることです。 ルックアップ値は（整数）4です。 スキャン.................. FOUND | レコードを取得しています... | BYTE_1 | BYTE_2 | BYTE_3 | BYTE_4 | BYTE_5 | BYTE_6 | BYTE_7 | BYTE_8 | ... | ルックアップ値は（string） "some_val"（8バイト）です。 走査................................................. ....................................見つかった| レコードを取得しています... | BYTE_1 | BYTE_2 | BYTE_3 | BYTE_4 | BYTE_5 | BYTE_6 | BYTE_7 …

26 postgresql  index  query-performance  index-tuning  postgresql-performance 

この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 7年前に移行され ました。 public完全なテーブル構造、データ、関数、fk、pkなどを使用してスキーマを同じデータベースにコピーする方法。Postgresの バージョンは8.4 PSです。データベースではなくスキーマをコピーする必要があります。

26 postgresql 

この質問は、データベース管理者のStack Exchangeで回答できるため、Server Faultから移行されました。 2年前に移行され ました。 エラー 無効なタイムスタンプを含むタプルを削除しようとしています DELETE FROM comments WHERE date > '1 Jan 9999' OR date < '1 Jan 2000' OR date_found > '1 Jan 9999' OR date_found < '1 Jan 2000'; で終わる ERROR: attempted to delete invisible tuple 2009年には、OPで修正されたまったく同じエラーメッセージについて議論するメーリングリストがありますが、彼がそれをどのようにしたのか、またはこのエラーにつながったのかについての説明はありません。 Googleでヒットがなく、PostgreSQLの知識が限られているため、私は無力です。 腐敗の原因 OSカーネルがパニックになったときに、おそらくスワップが配置されている/ dev / md1を再構築しているときに、Debian 8で実行しているPostgreSQL 9.5.5サーバー（メモリ制限の上限を除くすべてのデフォルト設定）を実行しました。それ以前は、PostgreSQLは400GBのログファイルでほとんどすべてのディスク領域を使い果たしました。OSは二度と起動しなかったので、ディスクチェックは問題ありませんでした。念のため、LiveCDから起動し、各ブロックデバイスをイメージにバックアップしました。/ …

25 postgresql  recovery  corruption  postgresql-9.5  disaster-recovery 

私はすべてのスキーマのすべてのテーブルをリストすることができます > \dt *.* しかし、それはまた、私が気にする私のテーブルよりもはるかに多いシステムテーブルをリストしています。パブリックスキーマおよび定義したスキーマで作成したすべてのテーブル（および場合によってはビュー）が欲しいです。 ここで説明するように、スキーマを作成するときに検索パスに明示的にスキーマを追加することなく、これを行う方法を見つけたいと思っています。 /programming//a/12902069 編集： 受け入れられた答えに基づいて、次のビューを作成しました。 create view my_tables as select table_catalog, table_schema, table_name, table_type from information_schema.tables where table_schema not in ('pg_catalog', 'information_schema'); そして今、次のコマンドは私が欲しいものを与えてくれます： select * from my_tables;

25 postgresql  postgresql-9.1 

私の現在のプロジェクトは、基本的に工場文書管理システムの実行です。 とはいえ、いくつかのしわ（驚き、驚き）があります。いくつかのしわはプロジェクトにかなり固有のものですが、標準的な答えを持たない（とにかく見つけることができる）一般的な観察と質問がいくつかあり、それはより広い問題領域に適用できると思います。ここにはたくさんあり、StackExchangeのQ＆A形式に適しているかどうかはわかりませんが、a）答えられる質問であり、b）コミュニティに役立つほど具体的でないと思います。私の考慮事項のいくつかは私に固有のものですが、この質問は、SQLとNoSQLとその両方を決定することに直面している人にとって役に立つと思います。 背景： 作成しているWebアプリには、本質的に明らかにリレーショナルなデータと、ドキュメント指向のデータが含まれています。ケーキを持って食べたいです。 TL; DR：以下の＃5は匂いテストに合格すると思います。あなたは？単一のアプリケーションでSQLとNOSQLをこのように統合した経験はありますか？このクラスの問題に対するすべての可能なアプローチを以下にリストしようとしました。有望な代替案を見逃していませんか？ 複雑さ： 文書には多くの異なるクラスがあります。要件はすでに何十もの異なる文書を要求しています。この数は増えるだけです。可能な限り最良のケースは、ドメイン専門家がDBAやプログラマの介入なしに新しいドキュメントクラスの追加を処理できるように、単純なドメイン固有の言語、コード生成、および柔軟なスキーマを活用できるケースです。（注：Greenspunの第10規則を順守していることを既に認識しています） 以前の正常な書き込みの整合性は、プロジェクトの中心的な要件です。データはビジネスに不可欠です。書き込みに関するACIDの完全なセマンティクスは、正常に書き込まれたものが書き込まれたままであれば、犠牲になる可能性があります。 文書自体は複雑です。特定のケースのプロトタイプドキュメントでは、ドキュメントインスタンスごとに150以上の個別のデータを保存する必要があります。病理学的症例は1桁悪化する可能性がありますが、確かに2ではありません。 単一クラスのドキュメントは、後の時点で更新の対象となる移動ターゲットです。 Djangoをリレーショナルデータベースにフックすると、無料のものが好きです。django-nonrelフォークを使用するために2つのDjangoバージョンに戻る必要なく、景品を保持したいと思います。1.3にダウングレードするよりも、ORM全体をダンプする方が望ましいです。 本質的には、リレーショナルデータ（ユーザー、グループなどの典型的なWebアプリのもの、および複雑なクエリをリアルタイムで切り刻むことができる必要があるドキュメントメタデータ）とドキュメントデータ（たとえば、参加やクエリに関心のない数百のフィールド-データの唯一のユースケースは、入力された単一のドキュメントを表示することです。 私は私の好みの方法で健全性チェック（あなたが私の投稿履歴をチェックする場合、私はDBAではないという事実についてかなり明確です）を行い、他の解決のために出会ったすべてのオプションを列挙したかったですリレーショナルデータと非リレーショナルデータの両方を含む、ほぼ同様の問題。 提案されたソリューション： 1.ドキュメントクラスごとに1つのテーブル 各ドキュメントクラスは、すべてのメタデータとデータの列を持つ独自のテーブルを取得します。 利点： 標準のSQLデータモデルが使用されています。 リレーショナルデータは可能な限り最適な方法で処理されます。必要に応じて後で非正規化します。 Djangoのビルトイン管理インターフェイスはこれらのテーブルを内省することに慣れており、ORMは100％のデータをそのまま使用できます。 短所： メンテナンスの悪夢。数千（数十？）の列を持つ数十（数百？）のテーブル。 どのテーブルに書き込むかを正確に決定するアプリケーションレベルのロジック。テーブル名をクエリのパラメータにすることは悪臭を放ちます。 基本的に、すべてのビジネスロジックの変更にはスキーマの変更が必要です。 病理学的なケースでは、複数のテーブルにまたがる単一のフォームのデータをストライピングする必要があるかもしれません（参照：PostgreSQLテーブルの列の最大数は？）。 私たちはおそらく、人生と私たちを憎むことになるであろう本当の、神に正直なDBAを見つけるために行く必要があるでしょう。 2. EAVモデリング フィールドテーブルのみがあります。エンティティー属性値のモデリングはすでに十分に理解されています。完全を期すために含めました。2013年に開始される新しいプロジェクトは、意図的にEAVアプローチを採用するとは思わない。 利点： モデル化が簡単。 短所： クエリがより困難です。 DBレイヤーには、1つのアプリレベルのオブジェクトを構成するものを簡単に表現することはなくなりました。 DBレベルの制約チェックが失われます。 1つのテーブルの行数は、100〜1000倍の速度で増加します。おそらく将来の問題点はパフォーマンス面です。 限られたインデックス付けが可能。 ORMに関する限り、DBスキーマは無意味です。Webアプリのものを含むバッテリーは保持されますが、カスタムデータモデルにはカスタムクエリが必要になります。 3. PostgreSQL hstoreまたはjsonフィールドを使用します これらのフィールドタイプのいずれかは、リレーショナルDBのコンテキスト内でスキーマレスデータを格納するためのトリックを行います。私はすぐにこの溶液にジャンプしない唯一の理由は、（バージョン8.4それほどではないに導入された比較的新しいですその新しい）、私はそれにゼロ以前のエクスポージャーを持っていると私は疑わしいです。Mongoはドキュメント間の参照を処理できますが、簡単に正規化されたすてきなデータをすべてMongoに投げるのが不安になるのとまったく同じ理由で、間違っていると思います。 利点： Django ORMと組み込みの認証およびセッション管理の利点を活用できます。 すべてが、以前に他のプロジェクトで正常に使用した1つのバックエンドに残ります。 短所： 個人的にはこれに関する経験はありません。 あまり使用されている機能のようには見えません。NOSQLソリューションを検討している人々にはかなり推奨されているように見えますが、選択されているという証拠はあまりありません。これは、私が何かを見逃しているに違いないと思うようにします。 …

25 postgresql  mongodb  rdbms  document-oriented 

そのため、PostgreSQLを搭載したDebianサーバーはほとんどありません。歴史的に、これらのサーバーとPostgreSQLはLatin 9文字セットでローカライズされていましたが、当時は問題ありませんでした。現在、ポーランド語、ギリシャ語、中国語などを処理する必要があるため、それを変更することは大きな問題になります。 UTF8データベースを作成しようとすると、次のメッセージが表示されました。 エラー：UTF8のエンコードはロケールfr_FRに一致しません詳細：選択したLC_CTYPE設定にはLATIN9のエンコードが必要です。 私は昔のパルグーグルでいくつかのテーマについて調査しましたが、Debianの更新LANG、正しい文字セットでのPostgreSQLの再コンパイル、すべてのLC_システム変数およびその他のあいまいなソリューションの編集など、複雑すぎる手順しか見つかりませんでした。とりあえず、この問題はさておきましょう。 最近、それは再び戻ってきました。ギリシャ人は物を望み、ラテン語9は望んでいません。そして、私がこの問題を再び検討している間に、ある同僚が私のところに来て、「ええ、簡単だ、見て」と言いました。 彼は何も編集せず、手品をしませんでした。彼はこのSQLクエリを作成しました。 CREATE DATABASE my_utf8_db WITH ENCODING='UTF8' OWNER=admin TEMPLATE=template0 LC_COLLATE='C' LC_CTYPE='C' CONNECTION LIMIT=-1 TABLESPACE=pg_default; そして、それはうまくいきました。 私は実際には知りLC_CTYPE='C'ませんでしたが、これがGoogleの最初のソリューションやStack Overflowでも使用されていないことに驚きました。私は周りを見回しましたが、PostgreSQLのドキュメントに言及しているだけです。 LC_CTYPEがCまたはPOSIXの場合、任意の文字セットが許可されますが、LC_CTYPEの他の設定では、正しく機能する文字セットは1つだけです。LC_CTYPE設定はinitdbによって凍結されるため、クラスターの異なるデータベースで異なるエンコードを使用するための明らかな柔軟性は、CまたはPOSIXロケールを選択する場合を除いて、実際よりも理論的です（したがって、実際のロケール認識を無効にします）。 だから、これはあまりにも簡単で完璧すぎると思いました。マイナス面は何ですか？そして、私はまだ答えを見つけるのに苦労しています。だからここに投稿します： tl; dr：特定のローカライズで使用LC_CTYPE='C'することのマイナス面は何ですか？そうするのは悪いですか？私は何を壊すことを期待すべきですか？

25 postgresql  collation 

この質問は、データベース管理者のStack Exchangeで回答できるため、Stack Overflowから移行されました。 5年前に移行され ました。 私はccaを持っていたいくつかのテーブルを持つ9.1データベースのローカルインストールを持っています。300のmioレコードとデータベースは約20 GBに成長しました。その後、delete fromすべてのレコードを削除するコマンドを発行しました（使用する必要がありましたがtruncate、それを知りませんでした）。だから、ディスク領域を再利用するためにdbを完全に空にしましたが、それはまったく役に立ちません。私の問題はこれと同じように見えますが、解決策は提供されていません。私はすでにこのスレッドと「ディスク領域の回復」に関するドキュメントをチェックしましたが、それでも解決策が見つかりません。このコードを使用して、すべてのテーブルのサイズを取得します SELECT nspname || '.' || relname AS "relation", pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size" FROM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) WHERE nspname NOT IN ('pg_catalog', 'information_schema') AND C.relkind <> 'i' AND nspname !~ '^pg_toast' ORDER BY pg_total_relation_size(C.oid) DESC LIMIT 15; …

25 postgresql  disk-space