OpenEdge Table Partitioning simplifies maintenance and adds database flexibility. When combined with OpenEdge Pro2 you can migrate to a partitioned database and test its benefits with almost no downtime. If you haven’t upgraded, you’re missing out on some big wins for your database.
Just over two years ago when I joined the Progress OpenEdge development team, they were completing the first release of the Table Partitioning feature. I was extremely impressed by how complete the first release of this feature would be. Before Progress, I did a lot of work with PostgreSQL’s database partitioning functionality to help customers solve a variety of problems. Specifics included:
In all cases, the customer had run up against a scalability issue and properly partitioning the data helped address this. We were able to achieve excellent results with table partitioning, even though PostgreSQL did not at the time (and I believe still does not) provide the following capabilities available in OpenEdge Table Partitioning:
I considered the Progress implementation to be far more complete then the PostgreSQL implementation and a fantastic product. Despite all of this, customers and partners have been a little slow to adopt OpenEdge Table Partitioning. It has been more aggressively adopted within the PostgreSQL world. I have heard that OpenEdge customers are typically conservative in their adoption of new features. They love the fact that the database just works and it runs. If it works, why upgrade? Well, I would like to tell you why:
Table Partitioning provides you with a multitude of options for managing large data sets not available to you in previous releases. Here are just a few off the top of my head:
The biggest objection I have heard regarding the use of data partitioning is that people don’t want to pay the downtime or performance expense required to re-partition the data. There is a simple solution for that: Progress OpenEdge Pro2. OpenEdge Pro2 can easily be used to migrate a data non-partitioned database to a partitioned database. The beauty of this is that it can be done with limited impact on performance and with almost zero downtime. The formula I would use goes like this:
The outage time for something like this is quite minimal, and I now have the wins that OpenEdge Table Partitioning can bring.
If you are interested in taking this step forward, please let me know. I will personally work with you (and by extension so will several others on our team) to help make your efforts a success.
Want to learn more about Table Partitioning? Read our comprehensive Solution Brief: Table Partitioning for Improved Manageability and Availability. For advice on how to best implement Table Partitioning for success, check out this whitepaper drafted by Richard Banville and Dapeng Wu of the OpenEdge Development team: Table Partitioning: Improve Performance through Increased Concurrency.
Tom Kincaid is the VP of software development for OpenEdge, Corticon and Modulus at Progress Software. Prior to coming to Progress he was the VP of development at EnterpriseDB. He is one of the founding architects and managers of the Java 2 Enterprise Edition (J2EE) platform and was the Executive Director of Application Platforms at Sun Microsystems. Tom was also the Director of Quality Engineering at Red Hat Inc. He has spent his entire career in the Boston area and has almost 30 years of experience developing and delivering high quality software products for developers.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.