1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
PBXT To-Do List
===============
My thanks to all who have downloaded and tested PBXT. If an issue you reported before the date below is not on this list, please e-mail me again.
------- 2008-12-09
0063: The option for not using memory mapped files must be fixed.
0062: Dynamic option for using memory mapping on a table (Dimitri).
------- 2008-09-12
0061: Add records per key result to ha_pbxt:info() call (Mark).
------- 2008-08-31
0060: Add table option to determine if a table should be memory mapped or not (also requested by Dimitri).
0059: Add table options:
AVG_ROW_LENGTH [=] value
DATA DIRECTORY [=] 'absolute path to directory'
INDEX DIRECTORY [=] 'absolute path to directory'
MAX_ROWS [=] value
------- 2008-03-28
0058: Consolidate writes when changes in the log are applied to the database.
------- 2008-03-07
0057: Cluster updates onto a single page.
0056: Add checksum to index and data pages.
0055: When no index cache is available, the complete index must be flushed (not just single pages).
0054: Optimize indexes by not creating indexes that are a complete sub-set of some other index. In this case we must be able to identify part of an index as unique. For example: primary key (a, b), index (a, b, c). Here we would just create index (a, b, c), and specify that the part (a, b) must be unique. Operations on (a, b) will be directed to index (a, b, c).
0053: Check and test lock tables.
0052: Cache data log data in the handle data cache. Must be purged when a handle data record is written.
0051: Write data log data alternatively to the transaction log. The compactor must then compact transaction logs.
0050: [RESOLVED: RN126] Implement consistent write for indexes.
0049: [RESOLVED: RN114] Set the index block size to 4K, or 16K as used by InnoDB.
0048: [RESOLVED: RN110] Add row ID to indexes. This should only be set once the row is cleaned by the sweeper. Then the row ID can be used to make a quite check if the row is the most recent version.
------- 2007-06-19
0047: Test build with ./configure --with-innodb under Linux (Vadim).
0046: [RESOLVED: RN85] Add plug.in file to enable drop in compile under Linux.
0045: Provide libstdc++.so.6 binaries (Vadim).
0044: [RESOLVED: RN73] Limit number of file handles used per table (Brian).
0043: XA (two-phase commit) support (Peter).
------- 2007-03-13
0042: [RESOLVED: RN108] Implemement STATUS commands.
0041: Implement index prefix compression.
------- 2007-03-07
0040: [RESOLVED: RN60] Update in-place when a transaction updates the same record more than once.
0039: Set the number and size of the segments dynamically according to the amount of memory in the cache (and the number of CPUs?) (as discussed with: Peter & Vadim).
0038: [RESOLVED: RN133] Improve the efficiency of the locks by using atomic compare and swap (Peter & Vadim).
0037: [RESOLVED: RN133] Instead of a global LRU list, use a LRU list for segment of the cache (Peter & Vadim). [ Note: a global list using a TAS lock and change time (so that LRU is not always updated) is most efficient].
0036: Add support for deferred foreign key checking (requested by: Mark).
0035: [RESOLVED: RN71] Remove the 2000 table limit (reported by: Hakan).
------- 2007-02-28
0035: [RESOLVED: RN74, RN107] Build in the PBXT system parameters (currently they must be set using environment variables.
0034: [RESOLVED: RN117] Initial documentation (yes, it must be done!)
0033: Make the error code returned on lock error configurable.
0032: [RESOLVED: RN65] Create a source code pluggable version for Windows.
0031: [RESOLVED: RN66] PBXT corrupts the index file when the size exceeds 4 GB (reported by: Luciano)
0030: [RESOLVED: RN102] Implement pbxt_index_flush_delay. Postpones index writing in order to speed up imports. [Resolution uses that fact hat index entries that are missing are added during recovery. As a result, index flushing can be delayed.]
0029: [RESOLVED: RN103] Implement SELECT ... FOR UPDATE (recommended by: Robin).
------- 2007-02-14
0028: Implement CREATE TABLE ... DATA/INDEX DIRECTORY (suggested by: Robin).
------- 2006-12-06
0027: [RESOLVED: RN53] Bug in pbxt with query caching (reported by: Giuseppe) caused violation of transaction isolation.
------- 2006-08-05
0026: Implement BACKUP and RESTORE table (planned for the first post release version).
0025: Implement DISABLE/ENABLE KEYS. Works for FOREIGN KEYs, currently no plans to implement for disabling indexes.
0024: Implement ANALYZE TABLE (planned for the first post release version).
0023: Implement CHECK TABLE (planned for the first release candidate).
0022: [RESOLVED: RN18] Implement TRUNCATE TABLE and DELETE FROM <table>; (i.e. a DELETE without WHERE clause). Currently this function does not cause an error, but no rows are deleted.
------- 2006-07-06
0021: [RESOLVED: RN28] .../mysql-test/mysql-test-run --force --mysqld=--default-storage-engine=pbxt produces a number of errors (reported by: Hakan): As far as I can tell some failures are unnessary but others are bugs. All need to be checked.
------- 2006-07-03
0020: [RESOLVED: RN49] Implement referential integrity (planned for the first release candidate).
------- 2006-04-01
0019: [RESOLVED: RN28] mysql-test-run hangs on alter table (reported by: Hakan): Running a test like ./mysql-test-run.pl --mysqld=--default-storage-engine=pbxt, hangs on ALTER TABLE.
0018: Implement GEOMETRY date type. Note: There are currently no plans to implement this feature.
------- 2006-03-31
0017: [RESOLVED: RN37] MySQL 5.x Version (reported by: Ronald, Giuseppe).
0016: [RESOLVED: RN13] Hang on "DROP DATABASE" (reported by: Giuseppe). Load the world database (http://downloads.mysql.com/docs/world.sql) and convert all tables into PBXT. Then, the drop database command hangs.
0015: [RESOLVED: RN12] Implement isolation level "repeatable read" (reported by: Giuseppe). Current PBXT only supports isolation level "committed read". This means committed data can be seen no matter when it was committed. Use SELECT ... FOR UPDATE to guarantee repeatable read, on data already read.
0014: [RESOLVED: RN7] Two transactions cannot insert simaltaneously if they use auto_increment (reported by: Giuseppe). See also 0005.
0013: [RESOLVED: RN11] Implement buffered write (reported by: Giuseppe): Lack of buffered write leads to bad performance in operations such as ALTER TABLE ENGINE = PBXT and INSERT ... SELECT.
0012: [RESOLVED: RN18] TRUNCATE does not work (reported by: Giuseppe)
0011: [RESOLVED: RN2] Load Sakila Sample Database (reported by: Ronald): ALTER TABLE film ENGINE=PBXT; fails
0010: [RESOLVED: RN6] sql-bench (reported by: Dmitry): ./run-all-tests --create-options=TYPE=PBXT fails.
0009: [RESOLVED: RN29] 64-bit Linux (reported by: Hakan): PBXT current does not compile under 64-bit Linux.
------- 2006-03-16
0008: [RESOLVED: RN10] Enforcing the unique index constraint:
An index declared as "unique" must return a "duplicate unique key" error when inserting a duplicate value. The difficulty part of implementing this in PBXT is that we may encounter a duplicate value that has not yet been committed. The index reading thread must then wait for the transaction to commit or abort.
0007: [RESOLVED: RN9] Cleaning up empty index nodes:
The Lehman and Yoa algorithm used for indexing does not describe a way of cleaning up empty index nodes on-the-fly. A search of the relevant literature for an algorithm also turns up empty handed (periodic "reorg" is mostly suggested). I have subsequently devised an algorithm that will do the job. This needs to be implemented.
0006: [RESOLVED: RN8] Cache Balancing:
PBXT uses a number of small caches in order to improve concurrency (rather than one large cache). A process is required to manage the amount of cache memory used as a whole. The process must distribute the overall amount of memory available for caching over the small caches, according to demand.
0005: [RESOLVED: RN7] Implement a faster auto-increment method
Currently the auto-increment is handled by the default method used in MySQL. This is done by performing a "fetch-last" on the index for each insert to find the highest key value. This works well unless there are large number empty index nodes due to the problem described in (2) above.
PBXT Testing To-Do List
This is my first take on what still must be tested. My thanks to Ronald Bradford who is working on a generic testing framework that can be used to test PBXT.
0004: [RESOLVED: RN6, RN28] MySQL Tests:
Several tests (for mysql-test-run) written for other engines can be adapted and used to test PBXT.
0003: [RESOLVED: RN30] Multi-processor Test:
There is a difference between preemptive multitasking and true multitasking, which you have on a multi-processor (or dual core) machine. I don't expect any fundamental problems here, but it must be tested.
0002: [RESOLVED: RN5, RN30, RN43] Multi-user/locking Test:
How does the engine perform with a number of concurrent users running various transactions on a number of different tables?
This is a difficult test to write because it need to simulate a production situation. To test at least 2 or 3 machines is required. The idea is not to use too much data so that a lot of conflicts may occur.
0001: [RESOLVED: RN4, RN43] Load/Stability Test:
How does the engine perform under heavy load over a long period of time? How stable is the engine on power outage, etc?
The test could use a variation of the test program written for test (3) above. At least 3 test machines would be required. The test must be modified to cause as much activity as possible. The test should monitor the performance under load.
|