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

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

3
特定のデータベースとユーザーのsearch_pathは何ですか?
私は現在search_pathを見ることができます: show search_path ; そして、私search_pathは現在のセッションのために設定することができます: set search_path = "$user", public, postgis; 同様に、search_path特定のデータベースのを次のように永続的に設定できます。 alter database mydb set search_path = "$user", public, postgis ; そして、私はsearch_path特定の役割(ユーザー)に永久的に設定することができます: alter role johnny set search_path = "$user", public, postgis ; しかし、それらを変更する前に、データベースとロールの設定が(に関してsearch_path)であるかどうかを判断する方法を知りたいですか?

1
PostgreSQLおよびMySQLのスケーラビリティの制限
MySQLやPostgreSQLなどの非シャードリレーショナルデータベースのパフォーマンスは、10 TBを超えると「壊れる」と聞きました。 Netezza、Greenplum、Verticaなどでは思いつかないような制限が存在するのではないかと思いますが、これらの制限が定量化されている研究論文や正式なケーススタディに言及している人がいるかどうかを尋ねたいと思います。

1
ダウンタイムなしでのスキーマ変更とライブデータベースへのデータ移行のベストプラクティス
ダウンタイムなしでライブデータベースのスキーマをどのように変更しますか? たとえば、すべてが特定のユーザーに関連付けられている、メールアドレスなどのさまざまなユーザーデータを含むテーブルを持つPostgreSQLデータベースがあるとします。電子メールアドレスを新しい専用テーブルに移動する場合は、スキーマを変更してから、電子メールデータを新しいテーブルに移行する必要があります。元のテーブルへの書き込みを停止せずにこれを行うにはどうすればよいですか?確かに、古いテーブルから新しいテーブルにデータが上書きされる間、新しいデータは引き続き古いテーブルに書き込まれ、失われますよね? この問題はかなり頻繁に発生すると思いますが、それを処理するための標準的なソリューションが見つかりません。 この記事ではこの問題を扱いますが、手順3を本当に理解していませんでした。彼は両方のテーブルに書き込み、古いデータを最初のテーブルから新しいテーブルに移行するように言っています。古いデータのみを移行していることをどのように確認しますか? (HerokuでPostgreSQLを使用しています。)

2
pgAdmin IIIでデータを表示する方法
彼らがこれを難しくするなんて信じられない。データベース内のデータを表示する方法がわかりません。 pgAdmin IIIを使用して、テーブルにあるデータを簡単に確認する方法はありますか?別の方法として、私が使用できる、吸わないプログラムはありますか?

5
PostgreSQLでの積極的な自動バキューム
私はPostgreSQLに積極的にデータベースを自動バキュームさせようとしています。現在、自動バキュームを次のように構成しています。 autovacuum_vacuum_cost_delay = 0#コストベースのバキュームをオフにする autovacuum_vacuum_cost_limit = 10000#最大値 autovacuum_vacuum_threshold = 50#デフォルト値 autovacuum_vacuum_scale_factor = 0.2#デフォルト値 自動バキュームは、データベースに負荷がかかっていないときにのみ作動することに気付きました。そのため、ライブタプルよりもはるかに多くのデッドタプルが存在する状況に陥ります。例については、添付のスクリーンショットを参照してください。テーブルの1つには23個のライブタプルがありますが、16845個のデッドタプルがバキュームを待っています。それは非常識です! テスト実行が終了し、データベースサーバーがアイドル状態になると、自動バキュームが開始されます。これは、データベースが既に稼働しているため、デッドタプルの数が20%のライブタプル+ 50を超えるたびに自動バキュームを開始したいので、これは望ましくありません設定済み。サーバーがアイドル状態のときの自動バキュームは、私にとって役に立たない。なぜなら、実稼働サーバーは、サーバーが負荷がかかっている場合でも実行するために自動バキュームが必要な理由で、持続時間にわたって1000更新/秒に達することが予想されるためである。 不足しているものはありますか?サーバーの負荷が高いときに自動バキュームを実行するにはどうすればよいですか? 更新 これはロックの問題でしょうか?問題の表は、挿入後トリガーを介して移入されるサマリー表です。これらのテーブルはSHARE ROW EXCLUSIVEモードでロックされ、同じ行への同時書き込みを防ぎます。

3
外部cronのようなツールなしでPostgresqlで繰り返しタスクを実行する方法は?
ストアドプロシージャを定期的に呼び出したいです。Oracleでは、このためのジョブを作成します。Postgresqlは外部ツール(cronなど)とPgAgentを使用することで、これをうまく模倣できることがわかりました。 外部ツールを使用しない「内部」の代替手段をご存知ですか? pgAgentのコマンドラインに保存されているパスワードに関するセキュリティ上の懸念を回避したい。 パスワードを隠すための追加のシステム構成を避けたい(~/.pgpass)。 Postgresql 8.3 Linux RedHat 64ビット

3
新しいユーザーがテーブルを作成できるのはなぜですか?
新しく作成したユーザーがデータベースに接続した後にテーブルを作成できるのはなぜだろうかと思っています。私は1つのデータベースを持っていますproject2_core: postgres=# \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges ---------------+--------------+-----------+-------------+-------------+------------------------------- postgres | postgres | SQL_ASCII | C | C | project2_core | atm_project2 | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 | project2=CTc/project2 template0 | postgres | SQL_ASCII | C | C | …


3
PostgreSQLにUPSERTを実装する慣用的な方法
UPSERTPostgreSQLのさまざまな実装について読んだことがありますが、これらのソリューションはすべて比較的古く、または比較的エキゾチックです(たとえば、書き込み可能なCTEを使用)。 そして、これらのソリューションが推奨されているため古くなっているのか、それとも(ほとんどすべてがそうである)実稼働での使用に適さない単なるおもちゃの例であるのかをすぐに調べるのは、psqlの専門家ではありません。 PostgreSQLでUPSERTを実装する最もスレッドセーフな方法は何ですか?


5
PostgreSQLのSQLのすべてのビューをリストする方法は?
PostgreSQLでSQLコマンドを使用してデータベースのすべてのビューを一覧表示するにはどうすればよいですか? psql \dvコマンドの出力に似たものが欲しいのですが、ビュー名のリストだけが望ましいです。例えば、 SELECT ...; my_view_1 my_view_2 my_view_3 Ubuntu LinuxでPostgreSQL v9.1.4を実行しています。

2
Postgres 9.2でwork_memおよびshared_buffersを増やすと、クエリが大幅に遅くなります
16 GBのRAMを搭載した8コアのRHEL 6.3で実行されているPostgreSQL 9.2インスタンスがあります。サーバーはこのデータベース専用です。デフォルトのpostgresql.confはメモリ設定に関してかなり保守的であるため、Postgresがより多くのメモリを使用できるようにすることは良い考えだと思いました。驚いたことに、wiki.postgresql.org / wiki / Tuning_Your_PostgreSQL_Serverのアドバイスに従うと、実際に実行するすべてのクエリが大幅に遅くなりましたが、より複雑なクエリでは明らかに目立ちます。 pgtuneの実行も試してみました。これは、調整されたパラメーターを増やして次の推奨事項を提示しましたが、何も変わりませんでした。RAMサイズの1/4のshared_buffersが推奨されますが、これは他のアドバイス(特にPG wiki)に沿っているようです。 default_statistics_target = 50 maintenance_work_mem = 960MB constraint_exclusion = on checkpoint_completion_target = 0.9 effective_cache_size = 11GB work_mem = 96MB wal_buffers = 8MB checkpoint_segments = 16 shared_buffers = 3840MB max_connections = 80 設定を変更した後(を使用してreindex database)データベース全体のインデックスを再作成しようとしましたが、それも役に立ちませんでした。shared_buffersとwork_memをいじりました。非常に控えめなデフォルト値(128k / 1MB)から徐々に変更すると、パフォーマンスが徐々に低下します。 私は走ったEXPLAIN (ANALYZE,BUFFERS)いくつかのクエリにし、犯人はハッシュが大幅に遅くなりましょうということのようです。理由は明らかではありません。 特定の例を挙げると、次のクエリがあります。デフォルト構成で約2100ミリ秒、バッファーサイズを増やした構成で約3300ミリ秒で実行されます。 select count(*) from …

2
読み取りパフォーマンスのためのPostgreSQLの構成
私たちのシステムは大量のデータを書き込みます(ビッグデータシステムの一種)。書き込みパフォーマンスはニーズには十分ですが、読み取りパフォーマンスは本当に遅すぎます。 主キー(制約)構造は、すべてのテーブルで類似しています: timestamp(Timestamp) ; index(smallint) ; key(integer). テーブルには数百万行、さらには数十億行あり、通常、読み取り要求は特定の期間(タイムスタンプ/インデックス)とタグに対して行われます。通常、約20万行を返すクエリがあります。現在、1秒あたり約15,000行を読み取ることができますが、10倍高速にする必要があります。これは可能ですか?もし可能なら、どのように? 注: PostgreSQLはソフトウェアにパッケージ化されているため、ハードウェアはクライアントごとに異なります。 これは、テストに使用されるVMです。VMのホストは、24.0 GBのRAMを備えたWindows Server 2008 R2 x64です。 サーバー仕様(仮想マシンVMWare) Server 2008 R2 x64 2.00 GB of memory Intel Xeon W3520 @ 2.67GHz (2 cores) postgresql.conf 最適化 shared_buffers = 512MB (default: 32MB) effective_cache_size = 1024MB (default: 128MB) checkpoint_segment = 32 (default: 3) checkpoint_completion_target …

2
エラー:作成するスキーマが選択されていません
私はAmazon RDSのpostgresqlデータベースに取り組んでいますが、パブリックスキーマに何らかの問題があったことがわかっています(削除された可能性があります)。しかし、明らかにスキーマは存在し、とにかく問題は解決されません。次に、新しく作成された空のデータベースとのサンプルセッションを示します。 mydb=> CREATE TABLE distributors ( mydb(> did integer, mydb(> name varchar(40) UNIQUE mydb(> ); ERROR: no schema has been selected to create in mydb=> show search_path; search_path ---------------- "$user",public (1 row) mydb=> create schema public; ERROR: schema "public" already exists ヒントはありますか?何を探すべきですか? 解決しました。 ダニエルヴェリテの回答のおかげで、私は次のように解決しました。 grant usage on schema public …

3
通常のVACUUM ANALYZEは9.1でも引き続き推奨されますか?
UbuntuでPostgreSQL 9.1を使用しています。スケジュールはVACUUM ANALYZEまだ推奨されていますか、それとも自動バキュームですべてのニーズに対応できますか? 答えが「依存する」の場合: 大きなデータベースがあります(30 GiBの圧縮ダンプサイズ、200 GiBのデータディレクトリ) データベースにETLを実行し、週に300万行近くをインポートします 最も頻繁に変更されるテーブルはすべてマスターテーブルから継承され、マスターテーブルにはデータがありません(データは週ごとに分割されます) 時間ごとのロールアップを作成し、そこから毎日、毎週、毎月のレポートを作成します スケジュールVACUUM ANALYZEがレポートに影響しているので、私は尋ねています。5時間以上実行されますが、通常のデータベースインポートに影響を与えていたため、今週2回停止する必要がありました。check_postgresデータベースの大きな膨張を報告しないため、それは実際には問題ではありません。 ドキュメントから、autovacuumはトランザクションIDのラップアラウンドも処理する必要があります。質問が立っています:私はまだ必要VACUUM ANALYZEですか?
38 postgresql  etl  vacuum 

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