 | | | PBXT version 0.9.5 has been released | PBXT version 0.9.5 has been released 2006-07-06 - By Daevid Vincent
Back
Your site has a bunch of JS errors (using IE) so I can't roll over ANY of
the menus (left or upper right). I also cannot write to 'contact' because of
this same error. Hence I send it here... To the list... *sigh*
Can I also suggest not using a dark red hyperlink with black text. I didn't
even realize those were links until I randomly rolled over one and it
highlighted bright red.
D?VID
> -- --Original Message-- --
> From: Paul McCullagh [mailto:paul.mccullagh@(protected)]
> Sent: Wednesday, July 05, 2006 6:51 AM
> To: mysql@(protected)
> Subject: PBXT version 0.9.5 has been released
>
> Hi All,
>
> PBXT version 0.9.5 has been released and can be downloaded from
> http://www.primebase.com/xt.
>
> This version includes a number of major structural changes to the
> implementation in order to improve performance. In addition, all bugs
> reported so far have been fixed. For further information on this
> release, please read my blog, http://pbxt.blogspot.com, and the
> associated comments. Details of all changes made are given in the
> release notes below.
>
> PrimeBase XT (PBXT) is a new transactional database engine for MySQL.
> It has been designed for modern, web-based, high concurrency
> environments. The Beta release of PBXT is planned for September 2006.
> The current version is based on MySQL 4.1.16 and runs on Mac OS X and
> Linux. The next version will include support for the new 5.1 storage
> engine API and 64-bit processors.
>
> Any questions, comments and bug reports can be sent directly to me.
> Thanks for your support!
>
> Best regards,
>
> Paul McCullagh
> SNAP Innovation GmbH
>
>
> PBXT Release Notes
> =================>
> -- ---- 0.9.5 - 2006-07-03
>
> RN15: This version concludes the re-structuring of the PBXT
> implementation. I have made a number of major changes, including:
>
> - All files except the transaction logs are now associated with a
> particular table. All table related files begin with the name of the
> table. The extension indicates the function.
>
> - I have merged the handle and the fixed length row data for
> performance reasons.
>
> - Only the variable size component of a row is stored in the data log
> files. As a result the data logs can now be considered as a type of
> "overflow" area.
>
> - Memory mapped files are no longer used because it is not
> possible to
> flush changes to the disk.
>
> RN14: File names have the following forms:
>
> [table-name]-[table-id].xtr - These files contains the table row
> pointers. Each row pointer occupies 8 bytes and refers to a list of
> records. The file name also contains the table ID. This is a unique
> number which is used internally by XT to identify the table.
>
> [table-name].xtd - This file contains the fixed length data
> of a table.
> Each data item includes a handle and a record. The handle
> references a
> record in the data log file if the table contains variable length
> records.
>
> [table-name].xti - This file contains the index data of the table.
>
> [table-name]-[log-id].xtl - This is a data log file. It contains the
> variable length data of the table. A table may have any
> number of data
> log files, each with a unique ID.
>
> xtlog-[log-id].xt - These files are the transaction logs. Log entries
> that specify updates reference a data file record. Each active thread
> has its own transaction log in order to avoid contension.
>
> RN13: Fixed the bug "Hang on DROP DATABASE". [RESOLVED: 0016]
>
> RN12: PBXT currently only supports the "Serializable" transaction
> isolation level. This is the highest isolation level possible and
> includes the "repeatable-read" functionality [RESOLVED:
> 0015]. This is
> implemented by giving every transaction a snapshot of the database at
> the point when the transaction is started.
>
> If the transaction tries to update a record that was updated by some
> other transaction after the snapshot was taken, a locked error is
> returned. A deadlock can occur if 2 transactions update the
> same record
> in a different order. PBXT can detect all deadlocks.
>
> RN11: I have implemented write buffering on the table data files.
> [RESOLVED: 0013]
>
> RN10: The unique constraint (UNIQUE INDEX/PRIMARY KEY) is now checked
> correctly. [RESOLVED: 0008]
>
> RN9: I have implemented a conventional B-tree algorithm for
> the indices
> (instead of the Lehman and Yoa B*-link tree). Although this reduces
> concurrency it improves the performance of queries significantly
> because of the simplicity of the algorithm. Deletion is also
> implemented in a very simple manner. [RESOLVED: 0007]
>
> RN8: PBXT now has only 2 caches [RESOLVED: 0006]:
>
> The Index Cache (pbxt_index_cache_size): This is the amount of memory
> the PBXT storage engine uses to cache index data and row
> pointers. This
> is all the data in the files with the extensions '.xti' and '.xtr'.
> This cache is managed in blocks of 2K.
>
> The Record Cache (pbxt_record_cache_size): This is the amount
> of memory
> the PBXT storage engine uses to cache table row data (handles and
> records). This is all the data in the files with the extension '.xtd'.
>
> The size of the caches are determined by the values of the system
> variables pbxt_index_cache_size and pbxt_row_cache_size. By default
> these values are set to 32MB.
>
> RN7: Auto-increment is now implemented in memory. This is
> done by doing
> a MAX() select when a table is first opened to get the high value.
> After that, then high value is incremented in memory on INSERT. On
> UPDATE (or INSERT) the value in memory is adjusted if necessary. This
> method also makes it possible for rows to be inserted
> simultaneously on
> the same table. [RESOLVED: 0005, 0014]
>
> RN6: ./run-all-tests --create-options=TYPE=PBXT succeeds. [RESOLVED:
> 0004, 0019]
>
> RN5: Using sql-bench and my own Java based test I have confirmed that
> PBXT behaves correctly during multi-threaded access. [PARTIALY
> RESOLVED: 0002]
>
> RN4: Load/Stability test. Using sql-bench I have tested PBXT
> under load
> over a long period of time. [PARTIALY RESOLVED: 0001]
>
> -- ---- 0.9.2 - 2006-04-01
>
> RN3: Fixed a bug that cause the error "-6: Handle is out of range:
> [0:0]".
>
> RN2: Implemented SET, ENUM and YEAR data types.
>
> RN1: Fixed a bug in the error reporting when a table is
> created with a
> datatype that is not supported. [RESOLVED: 0011]
>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/mysql?unsub?evid@(protected)
>
>
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql?unsub=mysql@(protected)
|
|
|