Date: Sat, 31 Dec 2016 18:14:09 +0000 (UTC) From: Kurt Jaeger <pi@FreeBSD.org> To: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: svn commit: r430149 - head/databases/cego Message-ID: <201612311814.uBVIE9lw024584@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: pi Date: Sat Dec 31 18:14:09 2016 New Revision: 430149 URL: https://svnweb.freebsd.org/changeset/ports/430149 Log: databases/cego: update 2.32.3 -> 2.32.4 - Fixes and improvements for table export added In CegoXPorter::xmlExportable, the pOutStream pointer was deleted, which lead to a core dump ( pointer is already deleted by Element ) Row counter handling and messages have been improved - Change back to memove call in CegoBTreeNode:shiftEntries. Copying manually and bytewise decreased performance about two times for building up btree objects. This has been observed on native POSIX ( FreeBSD 11 ) but also on MSYS64 compiles - Improvements for CegoBTreeCursor. With the new introduced methods CegoBTreeNode::getMedPage and CegoBTreeNode::rightValue, the search for the appropriate subnode can be made with logarithmic efforts instead of linear search. To validate this improvement, the following query has been setup for a random filled table t1 select * from t1 ta where exists ( select * from t1 tb where tb.b = ta.b ); Execution time with the improved btree cursor was two times faster than with old implementation. - More performance improvements made for btree creation changed linear search efforts in CegoBTreeNode::getChildPage to logarithmic search efforts ( introduced lb /rb variable ) - Change in CegoBTreeManager::allocPage. Since for cache based creation, just a pageId must be allocated, the low level method CegoFileHandler::allocatePage is used.This avoids an unnessary bufferFix call for the new page - Introduced appendFid variable for CegoFileHandler class. In case of many managed datafiles, the last file with avaiable pages is used for the allocatePage method. - Performance comparison to MariaDB indicates now a better scaling from 2 million rows and up ( by using cego btree cache ) - Improvement modifications for btree implementation increased build up speed for just about 3 percent. It seems, the most time is used by calling shiftEntries method, where memory is moved via memmove. I observed, that 8k page size ( instead of 16k ) brought up some performance improvement for btree creation of about 100% ( for type string(60) with random values ) - More performance improvements in CegoBTreeManager and CegoBTreeNode, overall impact still has to be analysed - Fix in CegoTableManager added for alter table modify column, columns with existing btree or key objects can not be modified anymore - Further improvement approach in CegoBTreeManager to increase btree creation performance. BufferPage handles have been changed from native variables to pointer handles. This should reduce page access efforts in case of enabled btree cache Submitted by: Bjoern Lemke <lemke@lemke-it.com> Modified: head/databases/cego/Makefile head/databases/cego/distinfo Modified: head/databases/cego/Makefile ============================================================================== --- head/databases/cego/Makefile Sat Dec 31 18:13:49 2016 (r430148) +++ head/databases/cego/Makefile Sat Dec 31 18:14:09 2016 (r430149) @@ -1,7 +1,7 @@ # $FreeBSD$ PORTNAME= cego -PORTVERSION= 2.32.3 +PORTVERSION= 2.32.4 CATEGORIES= databases MASTER_SITES= http://www.lemke-it.com/ Modified: head/databases/cego/distinfo ============================================================================== --- head/databases/cego/distinfo Sat Dec 31 18:13:49 2016 (r430148) +++ head/databases/cego/distinfo Sat Dec 31 18:14:09 2016 (r430149) @@ -1,3 +1,3 @@ -TIMESTAMP = 1482570949 -SHA256 (cego-2.32.3.tar.gz) = a4a5c0800606f18349152e702502c766db278b5aa61703f7a7fd474ef55e13cd -SIZE (cego-2.32.3.tar.gz) = 1449191 +TIMESTAMP = 1483134754 +SHA256 (cego-2.32.4.tar.gz) = 8b5ebc092c758dd01891c0d1f8d6a3046780176ae247aa8fec92ad44d406a2f1 +SIZE (cego-2.32.4.tar.gz) = 1395960
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201612311814.uBVIE9lw024584>