2011年10月19~21日に開催された「INSIGHT OUT 2011」のセッション「PostgreSQLアーキテクチャ入門」の講演資料です。
「INSIGHT OUT 2011」の詳細については、以下を参照ください。
http://www.insight-tec.com/insight-out-2011.html
2011年10月19~21日に開催された「INSIGHT OUT 2011」のセッション「PostgreSQLアーキテクチャ入門」の講演資料です。
「INSIGHT OUT 2011」の詳細については、以下を参照ください。
http://www.insight-tec.com/insight-out-2011.html
Hadoop YARN is the next generation computing platform in Apache Hadoop with support for programming paradigms besides MapReduce. In the world of Big Data, one cannot solve all the problems wholly using the Map Reduce programming model. Typical installations run separate programming models like MR, MPI, graph-processing frameworks on individual clusters. Running fewer larger clusters is cheaper than running more small clusters. Therefore,_leveraging YARN to allow both MR and non-MR applications to run on top of a common cluster becomes more important from an economical and operational point of view. This talk will cover the different APIs and RPC protocols that are available for developers to implement new application frameworks on top of YARN. We will also go through a simple application which demonstrates how one can implement their own Application Master, schedule requests to the YARN resource-manager and then subsequently use the allocated resources to run user code on the NodeManagers.
セル生産方式におけるロボットの活用には様々な問題があるが,その一つとして 3 体以上の物体の組み立てが挙げられる.一般に,複数物体を同時に組み立てる際は,対象の部品をそれぞれロボットアームまたは治具でそれぞれ独立に保持することで組み立てを遂行すると考えられる.ただし,この方法ではロボットアームや治具を部品数と同じ数だけ必要とし,部品数が多いほどコスト面や設置スペースの関係で無駄が多くなる.この課題に対して音𣷓らは組み立て対象物に働く接触力等の解析により,治具等で固定されていない対象物が組み立て作業中に運動しにくい状態となる条件を求めた.すなわち,環境中の非把持対象物のロバスト性を考慮して,組み立て作業条件を検討している.本研究ではこの方策に基づいて,複数物体の組み立て作業を単腕マニピュレータで実行することを目的とする.このとき,対象物のロバスト性を考慮することで,仮組状態の複数物体を同時に扱う手法を提案する.作業対象としてパイプジョイントの組み立てを挙げ,簡易な道具を用いることで単腕マニピュレータで複数物体を同時に把持できることを示す.さらに,作業成功率の向上のために RGB-D カメラを用いた物体の位置検出に基づくロボット制御及び動作計画を実装する.
This paper discusses assembly operations using a single manipulator and a parallel gripper to simultaneously
grasp multiple objects and hold the group of temporarily assembled objects. Multiple robots and jigs generally operate
assembly tasks by constraining the target objects mechanically or geometrically to prevent them from moving. It is
necessary to analyze the physical interaction between the objects for such constraints to achieve the tasks with a single
gripper. In this paper, we focus on assembling pipe joints as an example and discuss constraining the motion of the
objects. Our demonstration shows that a simple tool can facilitate holding multiple objects with a single gripper.
【DLゼミ】XFeat: Accelerated Features for Lightweight Image Matchingharmonylab
公開URL:https://arxiv.org/pdf/2404.19174
出典:Guilherme Potje, Felipe Cadar, Andre Araujo, Renato Martins, Erickson R. ascimento: XFeat: Accelerated Features for Lightweight Image Matching, Proceedings of the 2024 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR) (2023)
概要:リソース効率に優れた特徴点マッチングのための軽量なアーキテクチャ「XFeat(Accelerated Features)」を提案します。手法は、局所的な特徴点の検出、抽出、マッチングのための畳み込みニューラルネットワークの基本的な設計を再検討します。特に、リソースが限られたデバイス向けに迅速かつ堅牢なアルゴリズムが必要とされるため、解像度を可能な限り高く保ちながら、ネットワークのチャネル数を制限します。さらに、スパース下でのマッチングを選択できる設計となっており、ナビゲーションやARなどのアプリケーションに適しています。XFeatは、高速かつ同等以上の精度を実現し、一般的なラップトップのCPU上でリアルタイムで動作します。
6. パーサ
• クエリの構文を解析して、文字列が正しい構文になっているかをチェック
• 構文が正しくなければエラーを返す
• 構文が正しければパースツリーの形に変換
• テーブル名やカラム名が実在するかは問わないので「ローパースツリー」
とも呼ばれる
SELECT oid FROM pg_proc WHERE oid = 1;
SELECT
TargetList
oid
RelationList
pg_proc
Qualifier
Expression
=
oid 1 6
8. アナライザ
• パースツリーをもとにどのような表や関数、演算子が参照されるか
を判断して、クエリツリーを作成する
• この時DBにテーブルが存在するかチェックし、存在したらテーブル名
をOIDに変換する
SELECT oid FROM pg_proc WHERE oid = 1;
SELECT
TargetList
oid
RelationList
pg_proc
Qualifier
Expression
=
oid 1
カタログ
oidに変更8
34. Seq Scanのコスト計算
Seq Scanのコスト= (DISK I/Oコスト)+(CPUコスト)
=(テーブル全ページ数×Seq_page_cost)
+(テーブル全行数×cpu_tuple_cost )
+(テーブル全行数×cpu_operator_cost)
34
=# EXPLAIN SELECT oid FROM pg_proc WHERE oid = 1;
QUERY PLAN
--------------------------------------------------
Seq Scan on pg_proc
(cost=0.00..92.12 rows=1 width=4)
Filter: (oid = 1::oid)
=# SELECT relpages,reltuples FROM pg_class
WHERE relname = 'pg_proc';
relpages | reltuples
----------+-----------
61 | 2490
総コスト
= (61×1.0) + (2490×0.01)
+ (2490×0.0025)
= 92.125
テーブル全行数
テーブル全ページ数
規定値0.0025
35. -----------------------------------------------------
Index Scan using pg_proc_oid_index on pg_proc
35
Index Scan 演算子
=# EXPLAIN SELECT oid FROM pg_proc WHERE oid=1;
QUERY PLAN
(cost=0.00..5.99 rows=1 width=4)
Index Cond: (oid = 1::oid)
• 特に大きなテーブルではコストが低くなるので選ば
れる可能性が高い
• Index Condが無い場合は、ソートの代わりとして使
われるインデックス順のフルスキャンを表す
36. 36
Index Scan について
• 検索条件に合致するインデックスがあれば検討する。
• 通常は対象行が少なければこちらが選択される。
• インデックスとテーブルを交互にアクセスする。
id列のインデックステーブル
id = 1
id = 11
id = 34
id = 45
・・・
1 11 45 100
検索条件に合う
リーフノードを探索
必要な行に
ランダムアクセス
Index Scan のコスト
= インデックスI/Oコスト+ テーブルI/Oコスト
+ インデックスCPUコスト+ テーブルCPUコスト
インデックスI/Oコスト
= 必要ページ数×sequential_page_cost(1)
テーブルI/Oコスト
= 必要行数×(1~4) ※
インデックスCPUコスト
= 必要行数×cpu_index_tuple_cost(0.005)
テーブルCPUコスト
= 必要行数×cpu_tuple_cost(0.01)
※
アクセスページがメモリサイズ
(effective_cache_size)の
何倍かでアクセスコストは変化
40. Index Only Scan
• 9.2で追加された
• 取得したい値にインデックスが含まれるとき、テーブ
ルのアクセスを省略して検索する
• 非常に高速(しかしindex only scanが選ばれるには
条件が…)
40
41. Index Only Scanのスキャン方法
• Index Only ScanはまずインデックスからVisibility
Mapを参照しに行く(早速テーブルには行かない)
• そして高速に値を返せるか返せないかは、実はこの
Visibility Mapにかかっている
→このVisibility Mapって一体何者なの?
41
43. Visibility Mapのbitが0だと
• テーブルにアクセスすることなくタプルの値を返す
43
SELECT id FROM table1 WHERE id BETWEEN 1 AND 11
ブロック
1
2
3
4
…
全タプル有効!
インデックス
1 11 34 45
テーブル
テーブルにアクセスしない
44. Visibility Mapのbitが1だと
• タプルの値が返せるものか判断するために通常の
テーブルアクセスを行う
無効タプルあり!
44
SELECT id FROM table1 WHERE id BETWEEN 1 AND 11
ブロック
1
2
3
4 1 11 34 45
…
インデックス
テーブル
1
本当に値返していいの?
テーブルにアクセスしよう
46. 46
Tid Scan 演算子
=# EXPLAIN SELECT oid FROM pg_proc WHERE ctid = '(0,1)';
QUERY PLAN
------------------------------------------------------
Tid Scan on pg_proc (cost=0.00..4.01 rows=1 width=4)
Filter: (ctid = '(0,1)'::tid)
• カラムタプルID
• “ctid=”がクエリに指定された場合のみ使われる
• 滅多に使わない、非常に速い
47. 処理を補助する演算子
47
分類演算子
テーブルスキャンSeq Scan
Index Scan
Bitmap Scan
Index Only Scan
Tid Scan
その他スキャンFunction Scan
テーブルの結合Nested Loop
Merge Join
Hash Join
分類演算子
検索結果に対して
作用
Group
limit
Unique
Aggregate
Group Aggregate
Result
結果の結合Append
SetOp
その他の処理を補
助
Sort
48. 48
Sort 演算子
=# EXPLAIN SELECT oid FROM pg_proc ORDER BY oid;
QUERY PLAN
---------------------------------------------
Sort (cost=181.55..185.92 rows=1747 width=4)
Sort Key: oid
-> Seq Scan on pg_proc
(cost=0.00..87.47 rows=1747 width=4)
• 明示的なソート: ORDER BY句
• 暗黙的なソート: Unique, Sort-Merge Join など
• 開始コストを持っている: 最初の値はすぐには返却
されない
54. Merge Join 演算子
# EXPLAIN SELECT * FROM pgbench_accounts AS a,
pgbench_tellers AS t where a.aid = t.tid;
QUERY PLAN
---------------------------------------------------------------
Merge Join (cost=5.94..11.25 rows=100 width=449)
Merge Cond: (a.aid = t.tid)
-> Index Scan using pgbench_accounts_pkey on pgbench_accounts a
(cost=0.42..39669.43 rows=1000000 width=97)
-> Sort (cost=5.32..5.57 rows=100 width=352)
Sort Key: t.tid
-> Seq Scan on pgbench_tellers t
(cost=0.00..2.00 rows=100 width=352)
• 二つのデータセットをJOINする:outerとinner
• Merge Right JoinとMerge In Joinがある
• データセットはあらかじめソートされていなければならず、また両方同
時に走査される。
54
59. 検索結果に対して作用する演算子
59
分類演算子
テーブルスキャンSeq Scan
Index Scan
Bitmap Scan
Index Only Scan
Tid Scan
その他スキャンFunction Scan
テーブルの結合Nested Loop
Merge Join
Hash Join
分類演算子
検索結果に対して
作用
Group
limit
Unique
Aggregate
Group Aggregate
Result
結果の結合Append
SetOp
その他の処理を補
助
Sort
60. 60
Limit 演算子
=# EXPLAIN SELECT oid FROM pg_proc LIMIT 5;
QUERY PLAN
------------------------------------------
Limit (cost=0.00..0.25 rows=5 width=4)
-> Seq Scan on pg_proc
(cost=0.00..87.47 rows=1747 width=4)
• 行は指定された数に等しい
• 最初の行を即時に返す
• 少量の開始コスト追加でオフセットの扱いも可
=# EXPLAIN SELECT oid FROM pg_proc LIMIT 5 OFFSET 5;
QUERY PLAN
------------------------------------------
Limit (cost=0.25..0.50 rows=5 width=4)
-> Seq Scan on pg_proc
(cost=0.00..87.47 rows=1747 width=4)
61. 61
Result 演算子
=# EXPLAIN SELECT 1 + 1 ;
QUERY PLAN
------------------------------------------
Result (cost=0.00..0.01 rows=1 width=0)
• 非テーブル問い合わせ
• テーブルを参照せずに結果が得られる場合
62. 結果を結合する演算子
62
分類演算子
テーブルスキャンSeq Scan
Index Scan
Bitmap Scan
Index Only Scan
Tid Scan
その他スキャンFunction Scan
テーブルの結合Nested Loop
Merge Join
Hash Join
分類演算子
検索結果に対して
作用
Group
limit
Unique
Aggregate
Group Aggregate
Result
結果の結合Append
SetOp
その他の処理を補
助
Sort
63. 63
Append 演算子
=# EXPLAIN SELECT oid FROM pg_proc
UNION ALL SELECT oid ORDER BY pg_proc;
QUERY PLAN
--------------------------------------------------------------
Append (cost=0.00..209.88 rows=3494 width=4)
-> Seq Scan on pg_proc (cost=0.00..87.47 rows=1747 width=4)
-> Seq Scan on pg_proc (cost=0.00..87.47 rows=1747 width=4)
• UNION (ALL) によるトリガー, 継承
• 開始コスト無し
• コストは単に全ての入力の合計
64. ------------------------------------------------------------------------
SetOp Intersect (cost=415.51..432.98 rows=349 width=4)
-> Subquery Scan "*SELECT* 1" (cost=0.00..104.94 rows=1747)
-> Subquery Scan "*SELECT* 2" (cost=0.00..104.94 rows=1747)
64
SetOp 演算子
=# EXPLAIN SELECT oid FROM pg_proc INTERSECT SELECT oid FROM pg_proc;
QUERY PLAN
-> Sort (cost=415.51..424.25 rows=3494 width=4)
Sort Key: oid
-> Append (cost=0.00..209.88 rows=3494 width=4)
-> Seq Scan on pg_proc (cost=0.00..87.47 rows=1747)
-> Seq Scan on pg_proc (cost=0.00..87.47 rows=1747)
• INTERSECT, INTERSECT ALL, EXCEPT, EXCEPT ALL句
のために使用される
– SetOp Intersect, Intersect All, Except, Except All
66. その前に
• どの問い合わせプランを選んでくれるかは基本的に
はPostgreSQL任せ
• プランナーは人より賢いのでむやみに強制しないほ
うが良い
• PostgreSQLコミュニティの考えも以下のよう
• We are not interested in implementing hints in the exact ways they are commonly
implemented on other databases. Proposals based on "because they've got them"
will not be welcomed. If you have an idea that avoids the problems that have been
observed with other hint systems, that could lead to valuable discussion.
• →他のDBにあるからなんて理由でPostgreSQLにヒント機能を持たせるのは歓迎し
ません。もし既存のヒント機能における問題点を避けれるようなアイデアがあるな
ら、そこで初めて議論しましょう。
• 他方では、プランナーは推測しかしない
– 統計情報を正しい状態に保つため定期的なANALYZEを。
66
68. pg_hint_planの実行例
=# EXPLAIN SELECT aid FROM pgbench_accounts ;
QUERY PLAN
---------------------------------------------------------------------
- Index Only Scan using pgbench_accounts_pkey on pgbench_accounts
(cost=0.00..2384.26 rows=100000 width=4)
=# /*+ SeqScan(pgbench_accounts) */ explain select aid from
pgbench_accounts;
QUERY PLAN
---------------------------------------------------------------------
- Seq Scan on pgbench_accounts (cost=0.00..2588.00 rows=100000
width=4)
68
70. 70
SETコマンドの実行例
=# EXPLAIN ANALYZE SELECT * FROM pg_class WHERE oid > 2112;
QUERY PLAN
------------------------------------------------
Seq Scan on pg_class
(cost=0.00..7.33 rows=62 width=164)
(actual time=0.087..1.700 rows=174 loops=1)
Filter: (oid > 2112::oid)
Total runtime: 2.413 ms
=# SET enable_seqscan = off;
=# EXPLAIN ANALYZE SELECT * ORDER BY pg_class WHERE oid > 2112;
QUERY PLAN
------------------------------------------------
Index Scan using pg_class_oid_index on pg_class
(cost=0.00..22.84 rows=62 width=164)
(actual time=0.144..1.802 rows=174 loops=1)
Index Cond: (oid > 2112::oid)
Total runtime: 2.653 ms
71. 71
Seq Scan の強制
=# EXPLAIN SELECT * FROM pg_class;
QUERY PLAN
-------------------------------------------------------
Seq Scan on pg_class
(cost=100000000.00..100000006.86 rows=186 width=164)
• 始動コストに100000000.0 を足すだけ
– /src/backend/optimizer/path/costsize.c