Dockerで分析環境構築(jupyter notebook + PostgreSQL) - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
PostgreSQLのデータをGUIでいじる（macOS/Postico） - Qiita
本記事の対象者 ちょこっとしたデータの修正をさくっとGUIでやりたい（できれば無料で） Excelのデータを簡単にPostgreSQLのテーブルに追加したい AWS RDSのデータをGUIで触りたい 記事の内容 PosticoでPostgreSQLをいじる方法を丁寧に説明しています PosgtreSQLをGUIでいじるソフト？ OSXで使えるpostgresqlのGUIクライアントを参照のこと PG Commander PSequel Postico CSVimport機能があると書かれていたPosticoをかるく使ってみた。 （実際はCSV importではなく、表データコピペ機能だった。後述参照） 一時的なことだと思われるが、pgadminはダウンロードしてもなぜか展開が出来なかったので試さなかった。 windowsは調べてない Posticoをインストールする インストール Post
PostgreSQL 10がやってくる！(その1) - Qiita
これはPostgreSQL Advent Calendar 2016の17日目の記事です。 先日のPGCONF.Asiaでネタ系を使い切ってしまったし、今年一年の自分の活動報告をここでするのもアレだし・・・ということで、今日は若干手抜きの記事になります。すいません。 PostgreSQL 10がやってくる！ 9月にPostgreSQL 9.6がリリースされ、みなさんパラレルクエリなどの新機能を満喫されているかと思いますが、もちろん次バージョンの開発もコミュニティは着々と進めています。 次のバージョンは9.7ではなく、10。ついに9から10になります。でもって、バージョン番号体系もx.y.zからx.yという体系に変わるようです。10以降は1桁目(x)がメジャーバージョン、2桁目(y)がマイナーバージョンを表すっぽい。 英語もC言語も読みたくないけど、10の新機能が知りたい PostgreSQ
PostgreSQL10でテーブルパーティションへのINSERT性能が大幅Upする件 - Qiita
これはPostgreSQL Advent Calendar 2016の13日目の記事です。 はじめに PostgreSQLには、継承とトリガを利用したテーブルパーティション機能が従来からありましたが、パーティションへのINSERTが非常に遅いという問題がありました。一方、それらの従来のテーブルパーティション機能の様々な問題を解決するため、NTT OSSセンタのAmit Langoteさん(@amitlan)が中心となり、新たな改善版テーブルパーティション機能が(記事執筆時点で)開発中のPostgreSQL10に取り込まれました。PostgreSQL10では、従来版と新機能版の2つのテーブルパーティション機能を利用できることになります。 この記事では、PostgreSQL10新機能版テーブルパーティションのINSERT性能が、従来のものに比べてどれだけ改善されているのか簡単に比較検証します。
PostgreSQL で json_array_elements を使って、JSON データ（オブジェクトの配列）を行として扱う方法 - Qiita
はじめに これは PostgreSQL Advent Calendar 2016 の 12日目の記事です。 この記事では、私が PostgreSQL を使うことにしていてほんとよかったぁ、と思った件について書きます。 背景 今回のネタは JSON データ型に対するデータ分析です。 一般論として、JSON のようなゆるいデータ型を使うことはあまりデータベース設計上、良いこととされていません。 JSON データ型を使うと、テーブル設計が明確ではなくなってしまいます。 また、データ設計が正規化されなくなってしまいますので、冗長なデータの持ち方になってしまいます。 とはいえ、開発上、事前に適切なデータ設計をすることは難しいことがあります。 JSON データ型を使うことによって、なんでもそこで格納させることができますので、 ついつい開発のとき使ってしまいます。そして、あとで技術的負債となってしまった
Heroku Postgres でデータベースサイズ100G、最大レコード数1億行のデータを扱っている話 - Qiita
はじめに この記事は、Heroku アドベントカレンダー 9日目です。 環境 Heroku Postgres Premium系 PostgreSQL Version 9.4.x データベースサイズ 100G超 テーブル数 100以上 こまってたこと クエリが遅くなってきた(当然でしょｗ バックアップに時間がかかる。（当たり前・・・ せっかく、Paas使っているのだからインフラで困りたくないじゃないですか！ ということで、Herokuさんのスケーラビリティでどうにかならないか調べました。 やったこと バックアップ作業を早くした 一時的にForkすることにしました。参考URLはこちら https://devcenter.heroku.com/articles/heroku-postgres-data-safety-and-continuous-protection#combining-phys
PostgreSQLで並列プログラミング - Qiita
この記事はPostgreSQL Advent Calendar 2016の9日目の記事です。 はじめに 昨日、開発中のPostgreSQL10.0についにパーティショニング専用の構文が導入され次のバージョンもとてが楽しみです。パーティショニングについての記事にしようかと思ったのですが、それは別の誰かが書いてくれると期待し、本日分では、PostgreSQLの最新バージョンである9.6にパラレルクエリが導入されパラレル化が熱い今、PostgreSQLのパラレル機構を使って並列プログラミングをする方法をご紹介します。 サンプルプログラムとしてpg_foobarというEXTENSIONを作成しました。githubリポジトリからダウンロードしてください。 実行例 pg_foobar EXTENSIONではpg_foobar()関数を用意しており、SELECT pg_foobar(2, 3, 4)と実
PostgreSQLで自動フェイルオーバーする方法 - Qiita
以前投稿したbgwokerで超簡易クラスタ管理を進化させたpg_keeperについて投稿。 コンセプト このツールのコンセプトは**「PostgreSQLの自動フェイルオーバーを簡単に設定する」です。 Pacemaker/corosyncやrepmgrを使えばより細かく、柔軟に設定することが出来ますが、その一方設定が面倒だったり、多くのケースではそこまで柔軟な設定は必要ないと思ったので、「マスタ、スレーブ2台構成でもっと簡単に可用性を向上させたい」**と思い作りました。 監視プロセスはPostgreSQLのプロセスの一つとして動作するので、高機能なクラスタリングミドルウェアによくある監視プロセス自体の起動・停止・監視等の作業は発生しません。 ただし、pg_keeperが対応しているのはマスタ1台、スタンバイ1台で同期レプリケーションを使用した場合のみです。 スタンバイを2台以上使用するケー
クエリチューニング: GROUP BY から LATERAL への書き換え - Qiita
「ユニークキーの GROUP BY」 を 「LATERAL」 に書き換えることで、クエリを性能改善できる可能性があります。 ここでは、非常にシンプルな書き換えの例を示します。 テーブルの準備 まずは、以下のような「部署」、「書籍」、「部署ごとの書籍在庫数」を管理する3つのテーブルを準備します。 なお、「書籍」テーブルは、データベースの状況をイメージしやすいように用意しているだけで、以降のクエリ書き換えでは特に使いません。 -- 部署のIDと名前を管理するテーブル department を作成 CREATE TABLE department (dept_id INTEGER PRIMARY KEY, name TEXT); -- 部署の情報を5件登録 COPY department (dept_id, name) FROM stdin; 1 総務部 2 開発部 3 財務部 4 企画部 5 購
PostgreSQLアンチパターン：外部キー制約の更新コストを見くびる - Qiita
CREATE TABLE reports ( id bigserial NOT NULL, user_id bigint NOT NULL, time_of_report timestamp without time zone NOT NULL, previous_report_id bigint REFERENCES reports (id), elapsed_time integer NOT NULL DEFAULT 0, CONSTRAINT reports_id_pkey PRIMARY KEY(id), CONSTRAINT reports_user_id_fkey FOREIGN KEY(user_id) REFERENCES users(id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE CASCADE ); CREATE INDEX
ad3e04e50357a1e758fc#_reference-a1b4100c3771c36dfbe6
SELECT COUNT(*) INTO before_count FROM table1; ... INSERT INTO table1 ...; ... SELECT COUNT(*) - brefore_count INTO registered_count FROM table1; なにかTABLEへの追加処理をしてますが、意図通りにできたかどうか、前後で COUNT(*)をとって、その差分を報告させようとしています。 複数のプロジェクトの複数のオーナーのコードで見かけたので、こんな初級アンチパターンも共有しときます。 なにがまずいの? COUNTは、シーケンシャル・スキャンしないと出てこない値なのです。アンチパターンでは、テーブル全体が対象ですから、主キーインデクスを総なめです。小さいテーブルのうちはいいのですが、運用の1000万行を越えるような巨大テーブルだと、主キーインデック
PostgresのRDSチューニング - Qiita
Wantedlyは今までRDSを初期設定のまま使っていました。ごめんなさい。 今回ちゃんとチューニングしてみたのでやってみた過程と結果を書きます。 ちなみにWantedlyはDBを幾つか持っていて、その中のDBの一つの最適化結果です。 NewRelic での測定の結果、平均31ms ぐらいかかっていたのが、 平均23ms ぐらいになっているので25％ぐらいの改善になりました。 インスタンスタイプ 使っているDBのインスタンスタイプです モデル: r3.4xlarge vCPU: 16 メモリ: 122GB SSDストレージ: 1 x 320G デフォルト値 RDSはパラメータグループを調節します。 それぞれのデフォルト値は書かれてないですが、以下のSQL出だすことができます。 => SELECT name,setting,unit FROM pg_settings; name | sett
Rails でシーケンシャルスキャンしているクエリを見つけて捗りたい - PostgreSQL 限定 - Qiita
------------ find Seq Scan query ------------ SELECT "todo".* FROM "todo" WHERE "todo"."user_id" = $1 LIMIT 1 QUERY PLAN --------------------------------------------------------------------------------------------- Limit (cost=10000000000.00..10000000001.67 rows=1 width=81) -> Seq Scan on todo (cost=10000000000.00..10000000001.67 rows=1 width=81) Filter: (user_id = 13) (3 rows) 内部の仕組み 簡単に機能実現のための実
PHPでデータベースに接続するときのまとめ - Qiita
【2021/10/15 追記】 この記事は更新が停止されています。現在では筆者の思想が変化している面もありますので，過去の記事として参考程度にご覧ください。PDO に関しては大きく変わっていない部分が多いとは思いますが， PHP 8.x 以降での動作保証はありません。 あらかじめ読んでおきたい記事 Qiita - 【PHP超入門】クラス～例外処理～PDOの基礎 by @7968 初心者がやりがちなミス 以下のどれかに1つでも当てはまるコードは見直す必要があります．付録にリンクを貼っておきましたので，「該当するかも？」という人はクリックして飛んで読んでください．太字にしてあるものは脆弱性に直結する危険度の高いものです． mysql_query などの非推奨関数を利用している SET NAMES あるいは SET CHARACTER SET などで文字コードを指定している そもそもデータベース
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLとPostgreSQLコマンド比較表 - Qiita
