タグ

2017年10月18日のブックマーク (5件)

  • ACM SIGMOD Blog

    Introduction In the last decade, the database community has identified cardinality estimation as the primary stumbling block for modern query optimizers.  Cardinality estimates, which estimate the size of sub-plan queries, are the primary basis for choosing between query plans, so poor estimates may result in catastrophic query execution plans. Research on this topic has consistently […] Read more

    tgk
    tgk 2017/10/18
  • A Look at How Postgres Executes a Tiny Join - Pat Shaughnessy

    Reading the Postgres source code is like attending a free Computer Science lecture, complete with working examples. Aside from saving and retrieving data, the primary feature of a relational database is the ability to execute join queries, to relate data in one table with data from another. While many developers are turning to NoSQL solutions, joining one set of data values with another remains on

    tgk
    tgk 2017/10/18
    Hash Joinの詳細。Bucketが2の累乗数になっているのは、割り算しないでAND演算で所属バケットを算出したいから
  • LATERALを使ってみよう | Let's POSTGRES

    笠原 辰仁 記事は2015年のPostgreSQL Advent Calendarの 12/3 の記事です。PostgreSQL9.3でサポートされたLATERALについての解説と使いどころについて紹介します。 はじめに PostgreSQLは幅広くSQL標準(ではないものも含む)の句や構文をサポートしており、それが製品の特徴の一つでもあります。PostgreSQL8.4でサポートされたWindow関数やWITH句はその引き合いに出されることが多いです。 さて、PostgreSQL9.3からはLATERALという句がサポートされています。やや地味で使われることが少ないため、ご存知の方は少ないかもしれません。しかし、LATERAL句は、使いどころによっては非常に強力な武器になります。 注意 記事ではテーブル定義や実行計画等を記載している箇所がありますが、幅の表示上、見やすいように改行して

    tgk
    tgk 2017/10/18
    LATERALによりSQLに処理手順の指定が持ち込まれたように見える。無くてもいいもののような気もするし、無いと解けない問題があるような気もする
  • PostgreSQLを遅くしている犯人はどこだ?

    出力内容を追いかけろ 実際に実行してみてどれだけの時間がかかったかは「actual time=」で表示される数値を追いかけることで確認可能です。例えば、前ページのリストの1行目に出力されている「actual time」だけを取り出すと、次のようになります。 ↓最初の1件目を取得するまでにかかった時間 (actual time=9006.586..9011.968 rows=16842 loops=1) ↑最終的に結果行全体を取得するのにかかった時間 特に、右側の数値である「最終的に結果行全体を取得するのにかかった時間」では、そのSQLの処理開始からの累積時間で表示されます。このため、当該行の処理が完了するまでにどれだけの時間がかかったかを確認できます。 これを基に、SQLの中でどの処理に最も時間がかかっていたのかを確認していきましょう。 Total runtimeが9022.840msであ

    PostgreSQLを遅くしている犯人はどこだ?
    tgk
    tgk 2017/10/18
    古いPostgreSQLでpredicate pushdownがされていませんでした、というケース。バグみたいなもの
  • ミドルウェア性能検証の手引き | 外道父の匠

    インフラエンジニアの多分、華形のお仕事の1つであるミドルウェアの性能検証を久々にガッツリやる機会がありましたので、検証作業の基的な項目について初心から振り返っておきたいと思います。読みやすさ度外視の詰め込み記事注意警報です。 世の中、雑な検証結果もちょいちょい散乱していて、私自身もそうならないよう注意を払っているわけですが、ガチでやると気をつける項目が多くて、自分で忘れたりしないようにと、誰かにやってもらいたい時に基を抑えてから取り掛かってもらうために、形にして残しておこうと思った次第であります。 目次 なぜ性能検証をするのか 環境の準備 インスタンスの用意 クライアントの用意 サーバーの用意 ボトルネックになりうる項目 CPU Utilization Memory Network Bandwidth Disk Bandwidth Disk IOPS Disk Latency Disk

    ミドルウェア性能検証の手引き | 外道父の匠