タグ

ブックマーク / www.nminoru.jp/~nminoru (5)

  • PostgreSQL のテーブルとブロックのデータ構造

    このページでは PostgreSQL のエクステンション(extension)を開発する人向けに、PostgreSQL のテーブルやインデックスを構成するブロックまたはページの内部構造について紹介する。 PostgreSQL の他の記事へのインデックスはここ。 更新履歴 (2017.03.01) 作成。 (2017.03.04) ヒープ操作、システムカタログ、Relation cache entry の説明を追加。 目次 1. はじめに 1.1 PostgreSQL データの構成要素 1.2 Object Identifier (OID) 1.3 データディレクトリ 2. リレーション(Relation) 2.1 リレーションの概要 2.2 データディレクトリ中のリレーションの実体 2.3 リレーションの構造 2.4 API を使った操作 2.4.1 Relation Cache Entr

    kamipo
    kamipo 2017/03/08
  • 文字列の照合順序(Collation)

    作成日:2014.03.13 更新履歴 (2014.0313) 2013年6月27日の日記と2014年3月3日の日記から作成。 目次 はじめに strcoll 関数 strxfrm 関数 疑問 UTF-8 の話 文字列照合順序(Collation) L1 Base Characters L2 Accents L3 Case/Variants L4 Punctuation Llast Identical ライブラリ実装 参考文献 コメント はじめに C 言語の文字列の比較は strcmp() を用いるのが一般的である。 この関数は 2 つの NULL 終端文字列を先頭から符号なしバイトとして比較し大小関係を決める。 一方、文字列が各国のロケール(locale)を持つ場合、言語・国固有の文字列の照合順序(collation)が存在する。 Collation に基づいて文字比較を行うには str

    kamipo
    kamipo 2015/03/23
  • [Linux] 同一サブネットに2枚以上の NIC が刺さっている場合の動作 - NAKAMURA Minoru's Diary

    2002 | 10 | 11 | 12 2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 1

  • Mostly-Concurrent Mark & Sweep GC のアルゴリズム

    目次 1. 前置き 2. HotSpot VM 1.4.x の GC の種類 3. Mostly-concurrent Mark & Sweep 4. 応用 4.1 世代別 GC との組み合わせ 4.2 カードマーキング (Card Marking) 4.3 並列化 (Parallel GC) 4.4 ビットワイズ・スイープ (Bitwise Sweep) 4.5 インクリメンタル・コンパクション (Incremental Compaction) 5. 参考文献 脚注 コメント 1. 背景 ガーベージコレクション(GC) には色々なアルゴリズムが存在するが、大雑把に言って Stop-the-World (STW) 型 GC と On-the-fly 型 GC に大別される。 STW 型の GC はプログラムの実行中にはガーベージの回収を行わず、メモリが枯渇した時になって始めてガーベージの回

    kamipo
    kamipo 2010/09/24
  • ビットを数える・探すアルゴリズム

    作成日:2004.05.04 修正日:2012.09.01 このページは 2003年の9/11、9/28 の日記をまとめて作成。 はじめに PowerPC 系や Alpha などには population count と呼ばれるレジスタ中の立っているビット数を数える命令が実装されている。 集合演算を行うライブラリを実装したい場合などに重宝しそうな命令である。 職場でこの population count 命令について話をしているうちにビットカウント操作をハードウェアで実装するのは得なのか?という点が議論になった。 CPU の設計をできるだけシンプルにするためには、複雑で使用頻度の低い命令は極力減らした方がよい。 例えば SPARC は命令セット中にビットカウント演算があるが、CPU 内には実装しないという方針をとっている(population 命令を実行すると不正命令例外が発生し、それを

    kamipo
    kamipo 2009/04/10
    かろうじてバージョン3が分かる程度
  • 1