Comments on: Paul McCullagh answers your questions about PBXT http://www.mysqlperformanceblog.com/2009/11/20/paul-mccullagh-answers-your-questions-about-pbxt/ Percona's MySQL & InnoDB performance and scalability blog Sat, 11 Feb 2012 16:45:54 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Patrick Casey http://www.mysqlperformanceblog.com/2009/11/20/paul-mccullagh-answers-your-questions-about-pbxt/comment-page-1/#comment-685800 Patrick Casey Fri, 27 Nov 2009 18:49:58 +0000 http://www.mysqlperformanceblog.com/?p=1771#comment-685800 Update: A couple of folks have pointed out to me (accurately) that I had a misunderstnding about the PBXT log file. Seems that each table has its own sequential set of log files "file per table" so a table scan really is just a table scan, not a database scan. Update: A couple of folks have pointed out to me (accurately) that I had a misunderstnding about the PBXT log file. Seems that each table has its own sequential set of log files “file per table” so a table scan really is just a table scan, not a database scan.

]]> By: Patrick Casey http://www.mysqlperformanceblog.com/2009/11/20/paul-mccullagh-answers-your-questions-about-pbxt/comment-page-1/#comment-685745 Patrick Casey Fri, 27 Nov 2009 17:36:05 +0000 http://www.mysqlperformanceblog.com/?p=1771#comment-685745 Having read through the PBXT white paper and the answers here, I had a followup for something that occurred to me. Seems like in PBXT, records are laid down s they are generated in contiguous log files. So if you take a particular table that's been written to more or less steadily over the life of the database, that table is going to be scattered throughout the sum total of all log segments. Which means that any full table scan is really going to be a full database scan, or alternately, a full index scan followed by nested lookups by handle. This is in contrast to the extent based system on something like INNODB or Oracle where the database engine tries to keep records from the same table in physically co-located blocks. Am I missing something here, or does this mean the PBXT is going to have issues with full table scans and hence is probably not a good choice for, say, a data warehouse? Having read through the PBXT white paper and the answers here, I had a followup for something that occurred to me.

Seems like in PBXT, records are laid down s they are generated in contiguous log files. So if you take a particular table that’s been written to more or less steadily over the life of the database, that table is going to be scattered throughout the sum total of all log segments.

Which means that any full table scan is really going to be a full database scan, or alternately, a full index scan followed by nested lookups by handle.

This is in contrast to the extent based system on something like INNODB or Oracle where the database engine tries to keep records from the same table in physically co-located blocks.

Am I missing something here, or does this mean the PBXT is going to have issues with full table scans and hence is probably not a good choice for, say, a data warehouse?

]]>