PBXT 1.5.02-beta

Milestone information

Project:
PBXT
Series:
1.5
Version:
1.5.02-beta
Released:
2010-07-15  
Registrant:
Paul McCullagh
Release registered:
2010-07-15
Active:
No. Drivers cannot target bugs and blueprints to this milestone.  

Download RDF metadata

Activities

Assigned to you:
No blueprints or bugs assigned to you.
Assignees:
No users assigned to blueprints and bugs.
Blueprints:
No blueprints are targeted to this milestone.
Bugs:
No bugs are targeted to this milestone.

Download files for this release

File Description Downloads

Release notes 

------- 1.5.02 Beta - 2010-07-15

RN2/14: Made several improvement to xtstat. The --display option now allows you to both add and remove statistics that you are interested in. To remove a statistic, prefix it with '~'. For example: --display=all,~xlog. Statistics with names like "wr/ms" have been changed to "wr.ms", because using '/' was missleading. The statistic is not "writes per milliseconds", but "write time in milliseconds". The --help options describes changes to xtstat in detail.

RN2/13: As an optimization I have removed marking data log records as deleted. This requires a little more work from the Compactor which has to check the records to make sure they are invalid (which requires a read of the handle data file). However, it avoids random writes of the data log files.

RN2/12: Added 3 new system variables for the second level cache:
- pbxt_dlog_lev2_cache_file: The full path of the file in which the level 2 data log cache is to be stored (default is ./pbxt/dlog-lev2-cache.xt)
- pbxt_dlog_lev2_cache_size: The size of the data log level 2 cache (default is 16GB)
- pbxt_dlog_lev2_cache_enabled: Enable PBXT data log level 2 cache (default is 0 - i.e. not enabled)

RN2/11: Added a second level cache for the data logs. The cache is a file. Blocks that drop out of the data log primary (in-memory) cache are written to the second level cache file. The cache file should be placed on SSD or Flash hardware for optimal performance. Note: for each K-bytes of level 2 cache, the engine allocates approximately 1 byte of memory to manage the cache.

RN2/10: Optimized log reading during compaction. The Compactor now uses the data log cache, and does not read records if they are already in the sequential read buffer.

RN2/9: The Compactor thread now writes to its own data log during garbage collection. Previously the Compactor wrote to the active data log. This had 2 drawbacks: it mixed both old and newly written data, and conflicted with foreground transaction commit by flooding the active data log.

------- 1.5.01 Beta - 2010-06-10

RN2/8: Added system variable pbxt_data_log_buffer_size. The engine allocates 2 buffers of this size. The buffer is used to cache data before it is written to the data log. The buffer should be large enough to contain the largest BLOB written to the database. If not large enough, it will be automatically resized. A large buffer reduces the number of I/Os, because it only needs to be flushed when full, and at the end of a transaction.

RN2/7: pbxt_transaction_buffer_size has been deprecated, use pbxt_trx_log_buffer_size instead.

RN2/6: Added a cache for the data log (dlog-*.xt) files. The system variable pbxt_data_log_cache_size indicates the amount of memory to be allocated to the data log cache. The default is 16MB.

RN2/5: pbxt_log_cache_size has been deprecated, use pbxt_trx_log_cache_size instead. pbxt_log_file_threshold has been deprecated, use pbxt_trx_log_threshold instead. These names have been changed to avoid confusion with the data log system variables.

RN2/4: Extended record data is now no longer read by default on DELETE. The data is only read if it is required to find the record (i.e. contains "read" fields). All fields must be read for UPDATE because rows that are not changed need to be copied and rows that are changed are compared to the new value and only modified if they differ from the new value. Index coverage is now supported for both UPDATE and DELETE statement.

RN2/3: Changed the way the engine determines if a data log can be deleted. The data logs to be deleted are no longer stored in the checkpoint. Instead we not the "delete position" in the data log header. The delete position is the point in the transaction log where the "delete data log" record is inserted. Once all processes have read past this point (recover as well), it is safe to remove the data log.

RN2/2: Data logs are now written in the same manner as transactions logs. Previously, each thread had it's own data log for writing. Tests showed that this did not increase disk throughput. Far more useful is the ability to do "group commit". This is now possible on the data logs. All threads now write the same data log, and use the same "double-buffering" mechanism as the transaction log.
Other changes include:
- Merging of the data log sequential read functions into the transaction log sequential read functions.
- Data logs are now pre-allocated and zero filled, like the transaction logs.
- Added hooks for a data log cache.
- Reduced locking during compaction. Recovery now checks that a moved data log record is valid. Data logs are no longer deleted on recovery.

RN2/1: Fixed bug #430637: 'ERROR -86: Too many threads' reported during concurrecy test. I have removed the maximum thread limit. The system variable pbxt_max_threads has been depricated, and will no longer be supported in 1.1.

Changelog 

This release does not have a changelog.

0 blueprints and 0 bugs targeted

There are no feature specifications or bug tasks targeted to this milestone. The project's maintainer, driver, or bug supervisor can target specifications and bug tasks to this milestone to track the things that are expected to be completed for the release.

This milestone contains Public information
Everyone can see this information.