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

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


2
PostgreSQLからミリ秒単位でタイムスタンプ列を取得する方法は?
timestamp without time zone default now()PostgreSQLデータベースにtype で「作成」された列があります。 列を選択すると、デフォルトで見やすく読みやすい形式になります。 SELECT created FROM mytable; created --------------------------- 2011-05-17 10:40:28.876944 しかし、私はミリ秒だけでタイムスタンプを取得したい(ロングとして)。このようなもの: SELECT myformat(created)FROM mytable; created ----------------- 2432432343876944 PostgreSQLからミリ秒単位でタイムスタンプ列を取得するにはどうすればよいですか? ジャックへの応答: 私はあなたと同じ違いを取得します(-3600)が、使用するtimestamp with time zoneと、「エラー」または違いは「1970-01-01」がタイムゾーンを取得するためであることがわかります+01。 create table my_table_2(created timestamp with time zone); CREATE TABLE insert into my_table_2 (created) values (now()), ('1970-01-01'); INSERT 0 2 select created, …

4
空間インデックスは「範囲-順序-制限」クエリに役立ちますか
R-tree / spatialインデックスに適しているので、特にPostgresに対してこの質問をすること。 次の表に、単語とその頻度のツリー構造(ネストされたセットモデル)を示します。 lexikon ------- _id integer PRIMARY KEY word text frequency integer lset integer UNIQUE KEY rset integer UNIQUE KEY そしてクエリ: SELECT word FROM lexikon WHERE lset BETWEEN @Low AND @High ORDER BY frequency DESC LIMIT @N カバリングインデックス(lset, frequency, word)が有効であると思いlsetますが、(@High, @Low)範囲内の値が多すぎるとうまく機能しない可能性があります。 (frequency DESC)そのインデックスを使用した検索@Nが範囲条件に一致する行を早期に生成する場合、単純なインデックスで十分な場合もあります。 しかし、パフォーマンスはパラメーター値に大きく依存するようです。 範囲(@Low, @High)が広いか狭いかに関係なく、また、頻度の高い単語が幸運にも選択された範囲内にあるかどうかにかかわらず、高速に実行する方法はありますか? Rツリー/空間インデックスは役立ちますか? インデックスの追加、クエリの書き換え、テーブルの再設計、制限はありません。

2
PostgreSQLクライアントにSSLの使用を強制しますか?
で構成しssl = onましたpostgresql.conf(および証明書などをインストールしました)。これにより、すべてのクライアントが常にSSL経由で接続されるようになりますか? (つまり、SSL暗号化なしでssl = onは接続できなくなるのですか?) すべてのクライアントが常にSSL / TLS経由で接続することを保証する他の方法はありますか? よろしく、KajMagnus
29 postgresql 

1
インデックス付きJSONBとhstore
この段階では、可能な限り少ない仮定(Webアプリの実際の進化に関する)でデータベース設計を決定しようとしています。 JOINSが高価であることを理解するための最初のステップとして、多数の正規化された小さなテーブルではなく、少数のモノリシックテーブルを検討しています。2番目のポイントとして、hstoreと通常のテーブルとJSONB(GiSTインデックス付け)を使用することで混乱しています。 知っている(気軽に修正してください): 一般に、Postgresでは、hstoreは他のデータ型よりもパフォーマンスが良いことが知られています。FOSDEM PGDAYからのこのプレゼンテーションには、いくつかの興味深い統計があります(スライドの後半)。 https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf hstoreの利点は、高速インデックス(GiNまたはGiST)です。ただし、JSONBでは、GiNおよびGiSTインデックス付けをJSONデータに適用することもできます。 第2象限の専門家によるこのブログは、「この時点で、おそらくすべての新しいアプリケーションでhstoreの使用をjsonbに置き換える価値がある」と述べています(最後までスクロール):http ://blog.2ndquadrant.com/postgresql-anti-patterns-unnecessary -jsonhstore-dynamic-columns / だから私は次のことを決定したいと思います: データの主要な(構造化された)部分の場合:いくつかのリレーショナルテーブル(多くの列を持つ比較的大きい)に入れるべきですか、それともhstoreを使用する多数のキー値ストアである必要がありますか? アドホック(ユーザー提供/非構造化)データの場合、JSONまたはhstoreのアドホックキー値ストア(メインリレーショナルテーブルのいずれかにキーが格納されている)に格納する必要がありますか?

4
PostgreSQLで2つのテーブルに同じコンテンツがあるかどうかを確認する
これはすでにStack Overflowで要求されていますが、MySQLのみです。PostgreSQLを使用しています。残念ながら(そして驚くべきことに)PostgreSQLにはのようなものはないようですCHECKSUM table。 PostgreSQLのソリューションは問題ありませんが、一般的なソリューションの方が優れています。http://www.besttechtools.com/articles/article/sql-query-to-check-two-tables-have-identical-dataを見つけましたが、使用されているロジックがわかりません。 背景:データベースを生成するコードを書き直したので、古いコードと新しいコードが同じ結果を生成するかどうかを確認する必要があります。

2
範囲タイプの正確な等価性に起因する不適切なクエリプランの処理方法
tstzrange変数の正確な等価性が必要な更新を実行しています。〜1M行が変更され、クエリには〜13分かかります。の結果はここでEXPLAIN ANALYZE見ることができ、実際の結果はクエリプランナーが推定した結果とは大きく異なります。問題は、インデックススキャンで単一の行が返されることを期待していることです。t_range これは、範囲タイプの統計が他のタイプの統計とは異なる方法で保存されるという事実に関連しているようです。pg_stats列のビューを見ると、n_distinctis -1であり、他のフィールド(most_common_valsなどmost_common_freqs)は空です。 ただし、t_rangeどこかに統計が保存されている必要があります。完全に同等ではなくt_rangeで「within」を使用する非常に類似した更新の実行には約4分かかり、実質的に異なるクエリプランを使用します(こちらを参照)。一時テーブルのすべての行と履歴テーブルのかなりの部分が使用されるため、2番目のクエリプランは理にかなっています。さらに重要なことは、クエリプランナーがのフィルタに対してほぼ正しい行数を予測することt_rangeです。 の分布t_rangeは少し珍しいです。このテーブルを使用して別のテーブルの履歴状態を保存していますが、他のテーブルへの変更は大きなダンプで一度に発生するため、の値はあまり多くありませんt_range。の一意の値のそれぞれに対応するカウントはt_range次のとおりです。 t_range | count -------------------------------------------------------------------+--------- ["2014-06-12 20:58:21.447478+00","2014-06-27 07:00:00+00") | 994676 ["2014-06-12 20:58:21.447478+00","2014-08-01 01:22:14.621887+00") | 36791 ["2014-06-27 07:00:00+00","2014-08-01 07:00:01+00") | 1000403 ["2014-06-27 07:00:00+00",infinity) | 36791 ["2014-08-01 07:00:01+00",infinity) | 999753 t_range上記のdistinctのカウントは完了しているため、カーディナリティは〜3Mです(このうち〜1Mは、いずれかの更新クエリの影響を受けます)。 クエリ1のパフォーマンスがクエリ2よりもはるかに低いのはなぜですか?私の場合、クエリ2が適切な代替品ですが、正確な範囲の均等性が本当に必要な場合、Postgresでよりスマートなクエリプランを使用するにはどうすればよいですか? インデックス付きのテーブル定義(無関係な列の削除): Column | Type | Modifiers ---------------------+-----------+------------------------------------------------------------------------------ history_id | integer | not null default nextval('gtfs_stop_times_history_history_id_seq'::regclass) …

1
すべての列レコードを小文字に変換します
PostgreSQL 9.1を使用していますが、ユーザーテーブルにlogin列があります。 ログイン名は大文字と小文字が区別されます。たとえば、Bob、MikE、johnです。これらすべてのレコードを小文字に変換したいと思います。どうやってやるの?

2
SQLテキスト列を選択するときに長い行をラップする方法は?
長いテキスト列のあるテーブルから選択しています。長い行を最大行長に折り返したいです。 から: SELECT * FROM test; test_id | text --------+----------------------------------------------------------------------- 1 | Lorem ipsum dolor sit amet, consectetur adipiscing elit. Mauris lorem に: test_id | text --------+----------------------------- 1 | Lorem ipsum dolor sit amet,+ | consectetur adipiscing elit+ | . Mauris lorem
28 postgresql 



4
同じ値で行を更新すると、実際に行が更新されますか?
パフォーマンス関連の質問があります。マイケルという名のユーザーがいるとしましょう。次のクエリを実行します。 UPDATE users SET first_name = 'Michael' WHERE users.id = 123 同じ値に更新されている場合でも、クエリは実際に更新を実行しますか?もしそうなら、どうすればそれを防ぐことができますか?


2
同じSELECTリスト内の列エイリアスを参照する
古いMS-AccessベースのシステムをPostgreSQLに変換しています。Accessでは、SELECTで作成されたフィールドは、次のように、後のフィールドの方程式の一部として使用できます。 SELECT samples.id, samples.wet_weight / samples.dry_weight - 1 AS percent_water, 100 * percent_water AS percent_water_100 FROM samples; PostgreSQLでこれを行うと、Postgresはエラーをスローします。 エラー:列「percent_water」は存在しません。 サブ選択から選択することで、これを回避する方法は次のとおりです。 SELECT s1.id, s1.percent_water, 100 * s1.percent_water AS percent_water_100 FROM ( SELECT samples.id, samples.wet_weight / samples.dry_weight - 1 AS percent_water FROM samples ) s1; 複雑なネストを回避するための最初のコードブロックのようなショートカットはありますか?私は単に言うこともできます100 * (samples.wet_weight / samples.dry_weight - 1) …

3
Ubuntuサーバーでpostgres 9.1から9.3にアップグレードする
本番サーバー(ubuntu 13.10)をpostgresql 9.1で実行しています。 9.3のいくつかの機能を使用したいので、アップグレードしたい。 ダウンタイムが30分以内になるように、誰かが9.1から9.3にアップグレードするのを手伝ってもらえますか。とか、ぐらい? 主な関心事は、データの損失やファイルの冗長性の防止です。

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