Soumettre la recherche
Mettre en ligne
PostgreSQL実行計画入門@関西PostgreSQL勉強会
•
5 j'aime
•
1,224 vues
Satoshi Yamada
Suivre
関西PostgreSQL勉強会2015/10/21実施分の資料です 実行計画の簡単なお話をさせていただきました。
Lire moins
Lire la suite
Technologie
Signaler
Partager
Signaler
Partager
1 sur 64
Télécharger maintenant
Télécharger pour lire hors ligne
Recommandé
PostgreSQLの実行計画を読み解こう(OSC2015 Spring/Tokyo)
PostgreSQLの実行計画を読み解こう(OSC2015 Spring/Tokyo)
Satoshi Yamada
SQLチューニング入門 入門編
SQLチューニング入門 入門編
Miki Shimogai
押さえておきたい、PostgreSQL 13 の新機能!!(Open Source Conference 2021 Online/Hokkaido 発表資料)
押さえておきたい、PostgreSQL 13 の新機能!!(Open Source Conference 2021 Online/Hokkaido 発表資料)
NTT DATA Technology & Innovation
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界
Yoshinori Nakanishi
問合せ最適化インサイド
問合せ最適化インサイド
Takahiro Itagaki
PostgreSQL SQLチューニング入門 実践編(pgcon14j)
PostgreSQL SQLチューニング入門 実践編(pgcon14j)
Satoshi Yamada
pg_bigmで全文検索するときに気を付けたい5つのポイント(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_bigmで全文検索するときに気を付けたい5つのポイント(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
Recommandé
PostgreSQLの実行計画を読み解こう(OSC2015 Spring/Tokyo)
PostgreSQLの実行計画を読み解こう(OSC2015 Spring/Tokyo)
Satoshi Yamada
SQLチューニング入門 入門編
SQLチューニング入門 入門編
Miki Shimogai
押さえておきたい、PostgreSQL 13 の新機能!!(Open Source Conference 2021 Online/Hokkaido 発表資料)
押さえておきたい、PostgreSQL 13 の新機能!!(Open Source Conference 2021 Online/Hokkaido 発表資料)
NTT DATA Technology & Innovation
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
フックを使ったPostgreSQLの拡張機能を作ってみよう!(第33回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
あなたの知らないPostgreSQL監視の世界
あなたの知らないPostgreSQL監視の世界
Yoshinori Nakanishi
問合せ最適化インサイド
問合せ最適化インサイド
Takahiro Itagaki
PostgreSQL SQLチューニング入門 実践編(pgcon14j)
PostgreSQL SQLチューニング入門 実践編(pgcon14j)
Satoshi Yamada
pg_bigmで全文検索するときに気を付けたい5つのポイント(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_bigmで全文検索するときに気を付けたい5つのポイント(第23回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
NTT DATA Technology & Innovation
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
NTT DATA Technology & Innovation
20090107 Postgre Sqlチューニング(Sql編)
20090107 Postgre Sqlチューニング(Sql編)
Hiromu Shioya
忙しい人の5分で分かるDocker 2017年春Ver
忙しい人の5分で分かるDocker 2017年春Ver
Masahito Zembutsu
使ってみませんか?pg_hint_plan
使ってみませんか?pg_hint_plan
NTT DATA OSS Professional Services
PostgreSQLレプリケーション徹底紹介
PostgreSQLレプリケーション徹底紹介
NTT DATA OSS Professional Services
いまさら聞けないPostgreSQL運用管理
いまさら聞けないPostgreSQL運用管理
Uptime Technologies LLC (JP)
まずやっとくPostgreSQLチューニング
まずやっとくPostgreSQLチューニング
Kosuke Kida
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
Miki Shimogai
PostgreSQLバックアップの基本
PostgreSQLバックアップの基本
Uptime Technologies LLC (JP)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
NTT DATA Technology & Innovation
PostgreSQL:行数推定を読み解く
PostgreSQL:行数推定を読み解く
Hiroya Kabata
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
Masahiko Sawada
Vacuum徹底解説
Vacuum徹底解説
Masahiko Sawada
pg_hint_planを知る(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_hint_planを知る(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
pg_bigmと類似度検索
pg_bigmと類似度検索
Masahiko Sawada
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
NTT DATA Technology & Innovation
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
NTT DATA Technology & Innovation
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
Uptime Technologies LLC (JP)
PostgreSQLとPythonとSQL
PostgreSQLとPythonとSQL
Satoshi Yamada
Contenu connexe
Tendances
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
NTT DATA Technology & Innovation
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
NTT DATA Technology & Innovation
20090107 Postgre Sqlチューニング(Sql編)
20090107 Postgre Sqlチューニング(Sql編)
Hiromu Shioya
忙しい人の5分で分かるDocker 2017年春Ver
忙しい人の5分で分かるDocker 2017年春Ver
Masahito Zembutsu
使ってみませんか?pg_hint_plan
使ってみませんか?pg_hint_plan
NTT DATA OSS Professional Services
PostgreSQLレプリケーション徹底紹介
PostgreSQLレプリケーション徹底紹介
NTT DATA OSS Professional Services
いまさら聞けないPostgreSQL運用管理
いまさら聞けないPostgreSQL運用管理
Uptime Technologies LLC (JP)
まずやっとくPostgreSQLチューニング
まずやっとくPostgreSQLチューニング
Kosuke Kida
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
Miki Shimogai
PostgreSQLバックアップの基本
PostgreSQLバックアップの基本
Uptime Technologies LLC (JP)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
NTT DATA Technology & Innovation
PostgreSQL:行数推定を読み解く
PostgreSQL:行数推定を読み解く
Hiroya Kabata
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
Masahiko Sawada
Vacuum徹底解説
Vacuum徹底解説
Masahiko Sawada
pg_hint_planを知る(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_hint_planを知る(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
pg_bigmと類似度検索
pg_bigmと類似度検索
Masahiko Sawada
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
NTT DATA Technology & Innovation
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
NTT DATA Technology & Innovation
Tendances
(20)
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
PostgreSQL 12は ここがスゴイ! ~性能改善やpluggable storage engineなどの新機能を徹底解説~ (NTTデータ テクノ...
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
PostgreSQL開発コミュニティに参加しよう!(PostgreSQL Conference Japan 2021 発表資料)
20090107 Postgre Sqlチューニング(Sql編)
20090107 Postgre Sqlチューニング(Sql編)
忙しい人の5分で分かるDocker 2017年春Ver
忙しい人の5分で分かるDocker 2017年春Ver
使ってみませんか?pg_hint_plan
使ってみませんか?pg_hint_plan
PostgreSQLレプリケーション徹底紹介
PostgreSQLレプリケーション徹底紹介
いまさら聞けないPostgreSQL運用管理
いまさら聞けないPostgreSQL運用管理
まずやっとくPostgreSQLチューニング
まずやっとくPostgreSQLチューニング
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLクエリ実行の基礎知識 ~Explainを読み解こう~
PostgreSQLバックアップの基本
PostgreSQLバックアップの基本
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQLモニタリング機能の現状とこれから(Open Developers Conference 2020 Online 発表資料)
PostgreSQL:行数推定を読み解く
PostgreSQL:行数推定を読み解く
PostgreSQL 15 開発最新情報
PostgreSQL 15 開発最新情報
Vacuum徹底解説
Vacuum徹底解説
pg_hint_planを知る(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_hint_planを知る(第37回PostgreSQLアンカンファレンス@オンライン 発表資料)
pg_bigmと類似度検索
pg_bigmと類似度検索
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
オンライン物理バックアップの排他モードと非排他モードについて(第15回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
PostgreSQLのバグとの付き合い方 ~バグの調査からコミュニティへの報告、修正パッチ投稿まで~(PostgreSQL Conference Japa...
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
統計情報のリセットによるautovacuumへの影響について(第39回PostgreSQLアンカンファレンス@オンライン 発表資料)
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
大規模データ処理の定番OSS Hadoop / Spark 最新動向 - 2021秋 -(db tech showcase 2021 / ONLINE 発...
En vedette
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
Uptime Technologies LLC (JP)
PostgreSQLとPythonとSQL
PostgreSQLとPythonとSQL
Satoshi Yamada
bottle.pyをつかったチャットアプリ作成チュートリアル
bottle.pyをつかったチャットアプリ作成チュートリアル
Satoshi Yamada
PostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラ
NTT DATA OSS Professional Services
PostgreSQL 9.6 新機能紹介
PostgreSQL 9.6 新機能紹介
Masahiko Sawada
並列クエリを実行するPostgreSQLのアーキテクチャ
並列クエリを実行するPostgreSQLのアーキテクチャ
Kohei KaiGai
PostgreSQLによるデータ分析ことはじめ
PostgreSQLによるデータ分析ことはじめ
Ohyama Masanori
Djangoで業務改善したい
Djangoで業務改善したい
Satoshi Yamada
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
Shigeru Hanada
それFluentdで! #fluentd
それFluentdで! #fluentd
Atsuko Shibuya
PyconJP: Building a data preparation pipeline with Pandas and AWS Lambda
PyconJP: Building a data preparation pipeline with Pandas and AWS Lambda
Fabian Dubois
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
外道 父
[OSC2016沖縄]商用DBからPostgreSQLへの移行入門
[OSC2016沖縄]商用DBからPostgreSQLへの移行入門
Kosuke Kida
PostgreSQL共有バッファと関連ツール
PostgreSQL共有バッファと関連ツール
Masahiko Sawada
What’s new in 9.6, by PostgreSQL contributor
What’s new in 9.6, by PostgreSQL contributor
Masahiko Sawada
外部データラッパによる PostgreSQL の拡張
外部データラッパによる PostgreSQL の拡張
Shigeru Hanada
Hadoopカンファレンス20140707
Hadoopカンファレンス20140707
Recruit Technologies
PostgreSQL 9.5 新機能紹介
PostgreSQL 9.5 新機能紹介
NTT DATA OSS Professional Services
Elasticsearchを使うときの注意点 公開用スライド
Elasticsearchを使うときの注意点 公開用スライド
崇介 藤井
bottleで始めるWEBアプリの最初の一歩
bottleで始めるWEBアプリの最初の一歩
Satoshi Yamada
En vedette
(20)
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
PostgreSQLアーキテクチャ入門(PostgreSQL Conference 2012)
PostgreSQLとPythonとSQL
PostgreSQLとPythonとSQL
bottle.pyをつかったチャットアプリ作成チュートリアル
bottle.pyをつかったチャットアプリ作成チュートリアル
PostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQLの運用・監視にまつわるエトセトラ
PostgreSQL 9.6 新機能紹介
PostgreSQL 9.6 新機能紹介
並列クエリを実行するPostgreSQLのアーキテクチャ
並列クエリを実行するPostgreSQLのアーキテクチャ
PostgreSQLによるデータ分析ことはじめ
PostgreSQLによるデータ分析ことはじめ
Djangoで業務改善したい
Djangoで業務改善したい
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
それFluentdで! #fluentd
それFluentdで! #fluentd
PyconJP: Building a data preparation pipeline with Pandas and AWS Lambda
PyconJP: Building a data preparation pipeline with Pandas and AWS Lambda
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
Fluentd Meetup #2 @外道父 Fluentdを優しく見守る監視事例
[OSC2016沖縄]商用DBからPostgreSQLへの移行入門
[OSC2016沖縄]商用DBからPostgreSQLへの移行入門
PostgreSQL共有バッファと関連ツール
PostgreSQL共有バッファと関連ツール
What’s new in 9.6, by PostgreSQL contributor
What’s new in 9.6, by PostgreSQL contributor
外部データラッパによる PostgreSQL の拡張
外部データラッパによる PostgreSQL の拡張
Hadoopカンファレンス20140707
Hadoopカンファレンス20140707
PostgreSQL 9.5 新機能紹介
PostgreSQL 9.5 新機能紹介
Elasticsearchを使うときの注意点 公開用スライド
Elasticsearchを使うときの注意点 公開用スライド
bottleで始めるWEBアプリの最初の一歩
bottleで始めるWEBアプリの最初の一歩
Similaire à PostgreSQL実行計画入門@関西PostgreSQL勉強会
高速な倍精度指数関数expの実装
高速な倍精度指数関数expの実装
MITSUNARI Shigeo
PFDS 8.4.3 Real-Time Deques
PFDS 8.4.3 Real-Time Deques
昌平 村山
Rの高速化
Rの高速化
弘毅 露崎
Kof2016 postgresql-9.6
Kof2016 postgresql-9.6
Toshi Harada
Rでのtry関数によるエラー処理
Rでのtry関数によるエラー処理
wada, kazumi
MapReduce入門
MapReduce入門
Satoshi Noto
MapReduce/Spark/Tezのフェアな性能比較に向けて (Cloudera World Tokyo 2014 LT講演)
MapReduce/Spark/Tezのフェアな性能比較に向けて (Cloudera World Tokyo 2014 LT講演)
Hadoop / Spark Conference Japan
より深く知るオプティマイザとそのチューニング
より深く知るオプティマイザとそのチューニング
Yuto Hayamizu
CPANの依存モジュールをもう少し正しく検出したい
CPANの依存モジュールをもう少し正しく検出したい
charsbar
Material
Material
_TUNE_
Lisp tutorial for Pythonista : Day 1
Lisp tutorial for Pythonista : Day 1
Ransui Iso
HPC Phys-20201203
HPC Phys-20201203
MITSUNARI Shigeo
JPUGしくみ+アプリケーション勉強会(第20回)
JPUGしくみ+アプリケーション勉強会(第20回)
Yoshinori Nakanishi
分散メモリ環境におけるシェルスクリプトの高速化手法の提案
分散メモリ環境におけるシェルスクリプトの高速化手法の提案
Keisuke Umeno
C++によるソート入門
C++によるソート入門
AimingStudy
MapReduce解説
MapReduce解説
Shunsuke Aihara
Jpug study-pq 20170121
Jpug study-pq 20170121
Kosuke Kida
Similaire à PostgreSQL実行計画入門@関西PostgreSQL勉強会
(17)
高速な倍精度指数関数expの実装
高速な倍精度指数関数expの実装
PFDS 8.4.3 Real-Time Deques
PFDS 8.4.3 Real-Time Deques
Rの高速化
Rの高速化
Kof2016 postgresql-9.6
Kof2016 postgresql-9.6
Rでのtry関数によるエラー処理
Rでのtry関数によるエラー処理
MapReduce入門
MapReduce入門
MapReduce/Spark/Tezのフェアな性能比較に向けて (Cloudera World Tokyo 2014 LT講演)
MapReduce/Spark/Tezのフェアな性能比較に向けて (Cloudera World Tokyo 2014 LT講演)
より深く知るオプティマイザとそのチューニング
より深く知るオプティマイザとそのチューニング
CPANの依存モジュールをもう少し正しく検出したい
CPANの依存モジュールをもう少し正しく検出したい
Material
Material
Lisp tutorial for Pythonista : Day 1
Lisp tutorial for Pythonista : Day 1
HPC Phys-20201203
HPC Phys-20201203
JPUGしくみ+アプリケーション勉強会(第20回)
JPUGしくみ+アプリケーション勉強会(第20回)
分散メモリ環境におけるシェルスクリプトの高速化手法の提案
分散メモリ環境におけるシェルスクリプトの高速化手法の提案
C++によるソート入門
C++によるソート入門
MapReduce解説
MapReduce解説
Jpug study-pq 20170121
Jpug study-pq 20170121
Plus de Satoshi Yamada
Pythonで業務改善をしたときにあった問題(ライト版)
Pythonで業務改善をしたときにあった問題(ライト版)
Satoshi Yamada
pythonでemlファイルを扱う話
pythonでemlファイルを扱う話
Satoshi Yamada
Requestsで始める5分前帰社
Requestsで始める5分前帰社
Satoshi Yamada
DBエンジニアに必要だったPythonのスキル
DBエンジニアに必要だったPythonのスキル
Satoshi Yamada
本気でPythonで宛名書きした話
本気でPythonで宛名書きした話
Satoshi Yamada
10080分でPythonからIP Messeneger
10080分でPythonからIP Messeneger
Satoshi Yamada
15分で情シスに怒られる方法
15分で情シスに怒られる方法
Satoshi Yamada
PythonでテキストをJSONにした話(PyCon mini sapporo 2015)
PythonでテキストをJSONにした話(PyCon mini sapporo 2015)
Satoshi Yamada
201505 PostgreSQLアンカンファレンス(PL/Pythonで作るWEBアプリ)
201505 PostgreSQLアンカンファレンス(PL/Pythonで作るWEBアプリ)
Satoshi Yamada
Plus de Satoshi Yamada
(9)
Pythonで業務改善をしたときにあった問題(ライト版)
Pythonで業務改善をしたときにあった問題(ライト版)
pythonでemlファイルを扱う話
pythonでemlファイルを扱う話
Requestsで始める5分前帰社
Requestsで始める5分前帰社
DBエンジニアに必要だったPythonのスキル
DBエンジニアに必要だったPythonのスキル
本気でPythonで宛名書きした話
本気でPythonで宛名書きした話
10080分でPythonからIP Messeneger
10080分でPythonからIP Messeneger
15分で情シスに怒られる方法
15分で情シスに怒られる方法
PythonでテキストをJSONにした話(PyCon mini sapporo 2015)
PythonでテキストをJSONにした話(PyCon mini sapporo 2015)
201505 PostgreSQLアンカンファレンス(PL/Pythonで作るWEBアプリ)
201505 PostgreSQLアンカンファレンス(PL/Pythonで作るWEBアプリ)
PostgreSQL実行計画入門@関西PostgreSQL勉強会
1.
1 PostgreSQL 実行計画入門 2015/10/21 株式会社アシスト 山田 聡
2.
2 Who am I? ●
名前: 山田 聡 ● 所属:株式会社アシスト – サポートセンター – PostgreSQL/PPAS/Oracle担当 ● PostgreSQL歴 4年
3.
4 アジェンダ ● 実行計画って? ● PostgreSQLのプラン演算子 ●
実行計画の作り方 ● 実行計画の確認方法 ● 実際に見てみよう!
4.
5 実行計画って?
5.
6 実行計画って? 実行計画 欲しいデータへの 道筋
6.
7 交通手段:プラン演算子 目的地:欲しいデータ 実行計画って?
7.
8 実際は複数の交通手段(プラン演算子)を 組み合わせて目的地(データ)へたどり着く 実行計画って?
8.
9 交通手段 交通手段 交通手段 旅行 交通手段 交通手段 プラン演算子 実行計画 実行計画って?
9.
10 PostgreSQLのプラン演算子
10.
11 PostgreSQLのプラン演算子 ● 旅行で言う所の交通手段 ● プラン演算子を組み合わせる ●
状況ごとに適した物を選ぶ必要がある
11.
12 PostgreSQLのプラン演算子 分類 演算子 表スキャン Seq
Scan Index Scan Bitmap Index Scan Bitmap Heap Scan Index Only Scan Subquery Scan Tid Scan その他 Function Scan 結合 Nested Loop Merge Join Hash Join 分類 演算子 検索結果への処理 Group limit Unique Aggregate Group Aggregate Result 結果の結合 Append SetOp その他の処理補助 Sort
12.
13 PostgreSQLのプラン演算子 分類 演算子 表スキャン Seq
Scan Index Scan Bitmap Index Scan Bitmap Heap Scan Index Only Scan Subquery Scan Tid Scan その他 Function Scan 結合 Nested Loop Merge Join Hash Join 分類 演算子 検索結果への処理 Group limit Unique Aggregate Group Aggregate Result 結果の結合 Append SetOp その他の処理補助 Sort 単一表用
13.
14 (1).SeqScan (2).Index Scan 0 0 0 0 1 (4).Index
Only Scan 検索範囲:広 検索範囲:狭 1 0 1 0 0 (3).Bit Map Scan 検索範囲:中/特殊 検索範囲:特殊 PostgreSQLのプラン演算子
14.
15 ・最も基本的なアクセス方法 ・取り出す件数が多い時に有効 ・表の最後までアクセスする ・シーケンシャルアクセス (1).Seq Scan 検索範囲:広 PostgreSQLのプラン演算子 テーブル
15.
16 33 44 66 77 99 63 ・取り出す件数が少ない時に有効 ・インデックスとテーブルを 交互にアクセス ・ランダムアクセス (2).Index Scan 検索範囲:狭 PostgreSQLのプラン演算子 テーブルインデックス
16.
17 1 0 1 0 0 8.1〜 ・候補行をビットマップ化してアクセスする ・取り出す件数が中くらいの時に有効 ・インデックスを使った結合も可能 Bit Map インデックス (3).Bit Map
Scan 検索範囲:中/特殊 PostgreSQLのプラン演算子 テーブル
17.
18 0 0 0 0 1 ・9.2からの新機能 ・ほぼインデックスのみを検索 ・Visibility Mapを併用 9.2〜(4).Index Only
Scan 検索範囲:特殊 PostgreSQLのプラン演算子 インデックス Visibility Map
18.
19 PostgreSQLのプラン演算子 分類 演算子 表スキャン Seq
Scan Index Scan Bitmap Index Scan Bitmap Heap Scan Index Only Scan Subquery Scan Tid Scan その他 Function Scan 結合 Nested Loop Merge Join Hash Join 分類 演算子 検索結果への処理 Group limit Unique Aggregate Group Aggregate Result 結果の結合 Append SetOp その他の処理補助 Sort 複数表の結合用
19.
20 (1).Nested Loop Join 88 22 77 55 11 55 88 22 66 99 外部表 88 22 77 55 11 55 88 22 66 99 1 2 5 7 8 2 5 6 8 9 55 88 22 11 77 88 22 77 55 11 内部表 外部表
内部表 外部表 内部表 (2).Merge Join (3).Hash Join 特徴:いかなる場合でも 選択可能 特徴:ソートが完了すれば早い 特徴:ハッシュをオンメモリで 作成できればば早い 3つの結合方法 PostgreSQLのプラン演算子
20.
21 ・最も基本的な結合方法 ・ 外部表がの件数が少なく、 内部表にインデックスが あることが望ましい。 ・NとMが大きくなればなるほど コストが膨らむ 外部表 outer table 内部表 inner
table 特徴:いかなる場合でも 選択可能 PostgreSQLのプラン演算子 (1).Nested Loop Join
21.
22 PostgreSQLのプラン演算子 Nested Loop Join ●
少量データで最速 ● データ見積もりを失敗すると最遅 ● 速度の振れ幅が多い結合方法
22.
23 ・ 結合前にソートすることで 結合処理を削減 ・ ソートが出来れば早い。 (ソート済みのINDEXが ある列との相性が良い) 88 22 77 55 11 55 88 22 66 99 1 2 5 7 8 2 5 6 8 9 外部表 outer
table 内部表 inner table 特徴:ソートが完了すれば早い PostgreSQLのプラン演算子 (2).Merge Join
23.
24 PostgreSQLのプラン演算子 Merge Join ● ソートが全て ●
Indexがない結合でこれになるとTEMP大量
24.
25 ・ 内部表をベースにメモリ上に ハッシュ表を作り外部表は これにアクセスし 結合する ・
ハッシュ表を作ってしまえば その後の計算は早い。 外部表 outer table 内部表 inner tableハッシュ表 55 88 22 11 77 88 22 77 55 11 特徴:ハッシュをオンメモリで 作成できればば早い PostgreSQLのプラン演算子 (3).Hash Join
25.
26 PostgreSQLのプラン演算子 Hash Join ● WORK_MEMさえ余裕があれば安定 ●
データ量でのパフォーマンス幅が狭い
26.
27 PostgreSQLのプラン演算子 ● PostgreSQLの演算子は豊富 ● MySQLの結合はNested
Loopしかない 最適なプラン演算子の 組み合わせを求める事が重要
27.
28 実行計画の作り方
28.
29 実行計画の作り方 SQL そもそもSQL実行フローって パーサ アナライザ リライタ プランナ エグゼキュータ 結果
29.
30 実行計画の作り方 SQL そもそもSQL実行フローって パーサ アナライザ リライタ プランナ エグゼキュータ 結果 構文解析 SQL書換 実行計画作成 表存在チェック
30.
31 実行計画の作り方 SQL そもそもSQL実行フローって パーサ アナライザ リライタ プランナ エグゼキュータ 結果 実行計画作成 ※他のステップなどは過去の PostgreSQL勉強会の資料をご覧下さい http://www.slideshare.net/MikiShimogai/postgre-sql-explain
31.
32 ● プランナが統計情報を元に作る ● 統計情報は行数や値の偏り ●
複数の実行計画を候補として作る ● その中でコストが最も低いものを使う 実行計画の作り方
32.
33 ● プランナが統計情報を元に作る ● 統計情報は行数や値の偏り ●
複数の実行計画を候補として作る ● その中でコストが最も低いものを使う 実行計画の作り方 コスト単位 = シーケンシャルで 1ブロック読み込みとの相対値
33.
34 ● 統計情報の取得方法 – ANALYZE
<table_name>; – autovacuum でも取得される ● pg_statsでどんな値が取られたか確認可能 ● 統計情報は取得時点のオブジェクトの状態 実行計画の作り方
34.
35 実行計画の作り方 sampledb=# select *
from pg_stats where tablename='emp' and attname='job'; -[ RECORD 1 ]----------+-------------------------------------- schemaname | public tablename | emp attname | job inherited | f null_frac | 0 avg_width | 7 n_distinct | -0.357143 most_common_vals | {CLERK,SALESMAN,MANAGER,ANALYST} most_common_freqs | {0.285714,0.285714,0.214286,0.142857} histogram_bounds | correlation | -0.30989 most_common_elems | most_common_elem_freqs | elem_count_histogram | pg_statsの例
35.
36 実行計画の作り方 古い統計情報 プランナー (だいたい) Badな 実行計画 EMP表 (14行) EMP表 (1億行) 1億行追加 SELECT プランナは14行 として実行計画作成 SeqScanして 死ぬ ここでANALYZE →14行で認識
36.
37 実行計画の作り方 最新の統計情報 プランナー (だいたい) Goodな 実行計画 EMP表 (14行) ここでANALYZE →14行で認識 EMP表 (1億行) 1億行追加 SELECT もう一度ANALYZE →1億行で認識 IndexScanで 幸せ
37.
38 実行計画の確認方法
38.
39 ● 確認はEXPLAINコマンドを使用 ● EXPLAIN
<対象のSQL>; で利用可能 実行計画の確認方法 プランナの気持ちを 可視化するコマンド
39.
40 実行計画の確認方法 EXPLAIN select ename,
dname from emp e,dept d where e.deptno=d.deptno; Hash Join (cost=1.09..2.42 rows=14 width=15) Hash Cond: (e.deptno = d.deptno) -> Seq Scan on emp e (cost=0.00..1.14 rows=14 width=11) -> Hash (cost=1.04..1.04 rows=4 width=14) -> Seq Scan on dept d (cost=0.00..1.04 rows=4 width=14)
40.
41 実行計画の確認方法 EXPLAIN select ename,
dname from emp e,dept d where e.deptno=d.deptno; Hash Join (cost=1.09..2.42 rows=14 width=15) Hash Cond: (e.deptno = d.deptno) -> Seq Scan on emp e (cost=0.00..1.14 rows=14 width=11) -> Hash (cost=1.04..1.04 rows=4 width=14) -> Seq Scan on dept d (cost=0.00..1.04 rows=4 width=14)① ③ ② ④
41.
42 ● -> の部分が1ステップ ●
インデントが深い所から先に実行 ● インデントが同じなら上が先 実行計画の確認方法
42.
43 実行計画の確認方法 Seq Scan on
dept d Hash Join (cost=1.09..2.42 rows=14 width=15) Hash Cond: (e.deptno = d.deptno) -> Seq Scan on emp e (cost=0.00..1.14 rows=14 width=11) -> Hash (cost=1.04..1.04 rows=4 width=14) -> Seq Scan on dept d (cost=0.00..1.04 rows=4 width=14) Hash Seq Scan on emp e Hash Join
43.
44 実行計画の確認方法 EXPLAIN select ename,
dname from emp e,dept d where e.deptno=d.deptno; Hash Join (cost=1.09..2.42 rows=14 width=15) Hash Cond: (e.deptno = d.deptno) -> Seq Scan on emp e (cost=0.00..1.14 rows=14 width=11) -> Hash (cost=1.04..1.04 rows=4 width=14) -> Seq Scan on dept d (cost=0.00..1.04 rows=4 width=14)
44.
45 実行計画の確認方法 Hash Join (cost=1.09..2.42
rows=14 width=15) 見積りコスト (始動コスト..総コスト) 見積り行数 見積り平均行長
45.
46 実行計画の確認方法 Hash Join (cost=1.09..2.42
rows=14 width=15) 見積りコスト (始動コスト..総コスト) 見積り行数 見積り平均行長 大体総コストと行数を見ます
46.
47 ● EXPLAINの結果は統計情報からの見積り – コストが低いからといって最適なプランとは限らない –
統計情報が古いと誤った値になり得る ● 実際のデータからの情報をみるには ANALYZEオプションを追加 – 実際にSQLを発行して情報収集 – 負荷に注意!! 実行計画の確認方法
47.
48 SQL パーサ アナライザ リライタ プランナ エグゼキュータ 結果 EXPLAIN EXPLAIN ANALYZE 実行計画の確認方法
48.
49 実行計画の確認方法 EXPLAIN ANALYZE select
ename, dname from emp e,dept d where e.deptno=d.deptno; Hash Join (cost=1.09..2.42 rows=14 width=15) (actual time=11.835..11.868 rows=14 loops=1) Hash Cond: (e.deptno = d.deptno) -> Seq Scan on emp e (cost=0.00..1.14 rows=14 width=11) (actual time=11.714..11.723 rows=14 loops=1) -> Hash (cost=1.04..1.04 rows=4 width=14) (actual time=0.037..0.037 rows=4 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 1kB -> Seq Scan on dept d (cost=0.00..1.04 rows=4 width=14) (actual time=0.018..0.021 rows=4 loops=1) Total runtime: 11.950 ms
49.
50 実行計画の確認方法 EXPLAIN ANALYZE select
ename, dname from emp e,dept d where e.deptno=d.deptno; Hash Join (cost=1.09..2.42 rows=14 width=15) (actual time=11.835..11.868 rows=14 loops=1) Hash Cond: (e.deptno = d.deptno) -> Seq Scan on emp e (cost=0.00..1.14 rows=14 width=11) (actual time=11.714..11.723 rows=14 loops=1) -> Hash (cost=1.04..1.04 rows=4 width=14) (actual time=0.037..0.037 rows=4 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 1kB -> Seq Scan on dept d (cost=0.00..1.04 rows=4 width=14) (actual time=0.018..0.021 rows=4 loops=1) Total runtime: 11.950 ms
50.
51 実行計画の確認方法 Hash Join (cost=1.09..2.42
rows=14 width=15) (actual time=11.835..11.868 rows=14 loops=1) 処理時間 (1行目の時間..最終行の時間) 実際に戻った行数 ステップの実行回数 (Nested Loop等)
51.
52 実行計画の確認方法 Hash Join (cost=1.09..2.42
rows=14 width=15) (actual time=11.835..11.868 rows=14 loops=1) 実際に戻った行数 見積り行数 この2つが違う場合は統計情報が 最新じゃないことが多い
52.
53 実行計画の確認方法 Hash Join (cost=1.09..2.42
rows=14 width=15) (actual time=11.835..11.868 rows=14 loops=1) Hash Cond: (e.deptno = d.deptno) -> Seq Scan on emp e (cost=0.00..1.14 rows=14 width=11) (actual time=11.714..11.723 rows=14 loops=1) -> Hash (cost=1.04..1.04 rows=4 width=14) (actual time=0.037..0.037 rows=4 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 1kB -> Seq Scan on dept d (cost=0.00..1.04 rows=4 width=14) (actual time=0.018..0.021 rows=4 loops=1) ※cost/actual timeは子要素の値を含んでいる
53.
54 ● 2つのrowsがずれているところ – 統計情報のズレを疑う ●
actual timeが長い所 – ここを潰せると効果が大きい – 子要素で見積りのずれが発生してないかチェック ● costが高い所 – 統計が最新ならcostが高い所への対処も検討 実行計画の確認方法 みるべきポイント
54.
55 実際に見てみよう!
55.
56 Hash Join (cost=175782.31..405182.03 rows=53172
width=8) (actual time=1834.952..1844.389 rows=9 loops=1) Hash Cond: (exception.exception_id = exception_notice_map.exception_id) -> Seq Scan on exception (cost=0.00..144263.00 rows=5000000 width=4) (actual time=789.879..790.120 rows=1000 loops=1) Filter: (complete IS FALSE) Rows Removed by Filter: 9999000 -> Hash (cost=174037.01..174037.01 rows=106344 width=8) (actual time=1044.821..1044.821 rows=100202 loops=1) Buckets: 4096 Batches: 4 Memory Usage: 690kB -> Seq Scan on exception_notice_map (cost=0.00..174037.01 rows=106344 width=8) (actual time=0.081..991.670 rows=100202 loops=1) Filter: (notice_id = 3) Rows Removed by Filter: 9900798 Total runtime: 1844.486 ms 実際に見てみよう!
56.
57 Hash Join (cost=175782.31..405182.03 rows=53172
width=8) (actual time=1834.952..1844.389 rows=9 loops=1) Hash Cond: (exception.exception_id = exception_notice_map.exception_id) -> Seq Scan on exception (cost=0.00..144263.00 rows=5000000 width=4) (actual time=789.879..790.120 rows=1000 loops=1) Filter: (complete IS FALSE) Rows Removed by Filter: 9999000 -> Hash (cost=174037.01..174037.01 rows=106344 width=8) (actual time=1044.821..1044.821 rows=100202 loops=1) Buckets: 4096 Batches: 4 Memory Usage: 690kB -> Seq Scan on exception_notice_map (cost=0.00..174037.01 rows=106344 width=8) (actual time=0.081..991.670 rows=100202 loops=1) Filter: (notice_id = 3) Rows Removed by Filter: 9900798 Total runtime: 1844.486 ms 実際に見てみよう! このSQLは 4ステップ構成
57.
58 Hash Join (cost=175782.31..405182.03 rows=53172
width=8) (actual time=1834.952..1844.389 rows=9 loops=1) Hash Cond: (exception.exception_id = exception_notice_map.exception_id) -> Seq Scan on exception (cost=0.00..144263.00 rows=5000000 width=4) (actual time=789.879..790.120 rows=1000 loops=1) Filter: (complete IS FALSE) Rows Removed by Filter: 9999000 -> Hash (cost=174037.01..174037.01 rows=106344 width=8) (actual time=1044.821..1044.821 rows=100202 loops=1) Buckets: 4096 Batches: 4 Memory Usage: 690kB -> Seq Scan on exception_notice_map (cost=0.00..174037.01 rows=106344 width=8) (actual time=0.081..991.670 rows=100202 loops=1) Filter: (notice_id = 3) Rows Removed by Filter: 9900798 Total runtime: 1844.486 ms 実際に見てみよう! 見積りが ずれている こっちが先に ずれている
58.
59 ANALYZEしてみる
59.
60 Nested Loop (cost=0.43..152601.93 rows=11
width=8) (actual time=792.030..794.257 rows=9 loops=1) -> Seq Scan on exception (cost=0.00..144262.43 rows=1000 width=4) (actual time=790.677..790.885 rows=1000 loops=1) Filter: (complete IS FALSE) Rows Removed by Filter: 9999000 -> Index Scan using idx_nmap_exception_id on exception_notice_map (cost=0.43..8.33 rows=1 width=8) (actual time=0.003..0.003 rows=0 loops=1000) Index Cond: (exception_id = exception.exception_id) Filter: (notice_id = 3) Rows Removed by Filter: 1 Total runtime: 817.182 ms 実際に見てみよう! 少数取り出しなので NestedLoopに変更された
60.
61 まとめ
61.
62 ● 実行計画はプラン演算子の集合 ● プランナが自動で最適な構成を選んでくれる –
プランナのためにも統計情報を最新に! ● 確認にはEXPLAIN/EXPLAIN ANALYZE ● rowsやactual timeからあたりをつけてく まとめ
62.
63 ご清聴 ありがとうございました
63.
64 ● EXPLAINは初動調査ははほぼ同じ ● 実際は400行とかの実行計画を見る –
人間が見るもんじゃない・・・ – 自動化したい 余談
64.
65 [ { "Plan": { "Node Type":
"Hash Join", "Join Type": "Inner", "Startup Cost": 1.09, "Total Cost": 2.42, "Plan Rows": 14, "Plan Width": 52, "Actual Startup Time": 0.087, "Actual Total Time": 0.121, "Actual Rows": 14, "Actual Loops": 1, "Hash Cond": "(e.deptno = d.deptno)", "Plans": [ { "Node Type": "Seq Scan", "Parent Relationship": "Outer", "Relation Name": "emp", : ● FORMAT JSON オプション ● psql -Atで無駄な出力削除 ● JSONなので外部ツールと 連携可能 ● どなたか作りませんか?
Télécharger maintenant