xref: /linux/tools/perf/Documentation/db-export.txt (revision c532de5a67a70f8533d495f8f2aaa9a0491c3ad0)
1Database Export
2===============
3
4perf tool's python scripting engine:
5
6	tools/perf/util/scripting-engines/trace-event-python.c
7
8supports scripts:
9
10	tools/perf/scripts/python/export-to-sqlite.py
11	tools/perf/scripts/python/export-to-postgresql.py
12
13which export data to a SQLite3 or PostgreSQL database.
14
15The export process provides records with unique sequential ids which allows the
16data to be imported directly to a database and provides the relationships
17between tables.
18
19Over time it is possible to continue to expand the export while maintaining
20backward and forward compatibility, by following some simple rules:
21
221. Because of the nature of SQL, existing tables and columns can continue to be
23used so long as the names and meanings (and to some extent data types) remain
24the same.
25
262. New tables and columns can be added, without affecting existing SQL queries,
27so long as the new names are unique.
28
293. Scripts that use a database (e.g. exported-sql-viewer.py) can maintain
30backward compatibility by testing for the presence of new tables and columns
31before using them. e.g. function IsSelectable() in exported-sql-viewer.py
32
334. The export scripts themselves maintain forward compatibility (i.e. an existing
34script will continue to work with new versions of perf) by accepting a variable
35number of arguments (e.g. def call_return_table(*x)) i.e. perf can pass more
36arguments which old scripts will ignore.
37
385. The scripting engine tests for the existence of script handler functions
39before calling them.  The scripting engine can also test for the support of new
40or optional features by checking for the existence and value of script global
41variables.
42