Showing entries 37241 to 37250 of 43687
« 10 Newer Entries | 10 Older Entries »
What are the 3 most important replication features that you would like to see in the future?
Load data; Faster: Task parallelism

If you can't ride two horses at once, you shouldn't be in the circus --Proverb

The ETL load time can be reduced, for large data volumes by running several tasks in parallel rather than serial.

In addition to the data that we receive from the Sierra stores, in the given example, let us assume we receive sales transaction data from the Tundra line of stores as well. If the data file from the Tundra store arrives in the normalized structure, we might want to join the files together for data profiling. We can do this by loading the 3 files into 3 separate tables and join the 3 tables together in the data profiling SQL query. If this join needs to happen …

[Read more]
innotop 1.4.2 released

This release of the innotop MySQL and InnoDB monitor is a major upgrade in terms of functionality, code quality, and interface consistency. It is the result of me working for over a month to get innotop into shape for the recent MySQL Conference and Expo. This article is a summary of the changes and a look at what's coming next.

Serving SQL

How do you like your SQL served? Personally I like this type:

SELECT   dc.state
       , dd.year
       , dd.month
       , sum(fs.sales) as total_sales
FROM     fact_sales     fs,
         dim_date       dd,
         dim_customer   dc
WHERE    fs.customer_tk = dc.customer_tk
AND      fs.date_tk     = dd.date_tk
AND      dd.year IN ( 2006, 2007 )
GROUP BY dc.state
       , dd.year
       , dd.month

Obviously, it’s inspired by simple star schema querying. Anything goes for me, but I kinda like a little bit of “structure” in my SQL (no pun intended), just a little bit of overview.

What’s your favorite SQL format?

Matt

P.S. We will soon be launching PDI version 2.5.0, stay tuned!

What are the 3 most important replication features that you would like to see in the future?
FindBugs - Writing custom detectors (Part 2)

This is the second part of the "Howto write a FindBugs Bug Detector" (see the first part here). To understand why one would write the kind of detector mentioned here, you should read the first part if you do not already know it.

Last time I presented a detector that is able to detect static fields of the types java.util.Calendar and java.text.DateFormat. While declaring fields like this may be suspicious, there is not necessarily something wrong with the code. The real danger comes from calling methods on suchlike fields, especially if they are not synchronized to protect them against concurrent access. So in this article we will extend and improve the existing detector to cope with this problem.

Something to chew on

This a simple class that uses a static Calendar instance. It does not …

[Read more]
FindBugs - Writing custom detectors (Part 2)

This is the second part of the "Howto write a FindBugs Bug Detector" (see the first part here). To understand why one would write the kind of detector mentioned here, you should read the first part if you do not already know it.

Last time I presented a detector that is able to detect static fields of the types java.util.Calendar and java.text.DateFormat. While declaring fields like this may be suspicious, there is not necessarily something wrong with the code. The real danger comes from calling methods on suchlike fields, especially if they are not synchronized to protect them against concurrent access. So in this article we will extend and improve the existing detector to cope with this problem.

Something to chew on

This a simple class that uses a static Calendar instance. It does not …

[Read more]
Building a Storage Engine: Reading Data

Now that you can load an engine, we are going to look at reading data. For this we will need to implement three methods. We will also need the following schema:

CREATE TABLE `services` (
`a` varchar(125) NOT NULL DEFAULT '',
`b` text
) ENGINE=SKELETON DEFAULT CHARSET=latin1



Storage engines provide "handler" objects that are used to read/write/update tables. They inherit from the handler class defined in sql/handler.h.
The file ha_skeleton.cc holds the implementation of the handler for the Skeleton engine. Once a handler object is created it is cached and can be used for different tables that a particular storage engine controls. MySQL uses the open() and close() methods of handler object to tell the handler what table it should currently work with.

open() and close() are not called for each usage of a table, or each usage of a transaction.

For …

[Read more]
Thanks Jeffrey!

We just finished up our 2007 Users Conference and I'd really like to thank David Sceppa and Jeffrey McManus for presenting at the conference.  David is a program manager on the ADO.Net team at Microsoft and I had more than one person come up to me and tell me that having a Microsoft rep at the sessions really indicated that we were serious about working with Microsoft tools and that Microsoft seemed very willing to help with that.  True indeed.

Also, I really appreciated Jeffrey being willing to jump in last minute and do a presentation for us.  He does alot of traveling and presenting so I know his time is precious.  Jeffrey also recently made available a tool he wrote for generating a set of classes for a given database schema.  He calls it Cgen and you can read his announcement about it here.  Keep up the good …

[Read more]
Countless storage engines

Today everybody writes about MySQL Conference & Expo and I am not an exclusion. I am under impression of count of storage engines were presented. In good old time when Oracle bought InnoDB, MySQL did one step - announced MySQL supports Plugginable Storage Architecture. In that time nobody was able to predict what is the outcoming of such feature, but currently we all see it.
Let me list Transactional Storage Engines I heard of on Conference and main impression about.
InnoDB On the conference InnoDB presented two new interesting features - transparent ZIP of pages stored on disk. Potentially it can imporove performance of tasks with intensive I/O load a lot. Second feature - fast index build. Both should be available in 5.2 MySQL.
PBXT Interesting engine, mainly because of way to store new records "never updates" and just write to the end of file. Surely it has as benefits as and drawbacks. We …

[Read more]
Showing entries 37241 to 37250 of 43687
« 10 Newer Entries | 10 Older Entries »