Just a quick note to let you know that Postgres Plus Advanced Server 9.0 is now available! You can download the software from our downloads page and also get an idea of all the great new features in 9.0 by downloading and reading the “What’s New” white paper that’s on our resources page.
Thanks to the EnterpriseDB engineering team and all the customers whose feedback went into 9.0!
Postgres Plus Advanced Server 9.0 Now Available!Database Trends and Applications just published my recent column on how IT organizations are now embracing multiple open source database technologies and how the recent O’Reilly MySQL conference was a prime example of this in action. Check it out when you have time.
New column on IT organization trends with open source database technologiesI’m pleased to announce that we’ve certified both PostgreSQL 9.0 and Postgres Plus Standard Server 9.0 on Red Hat Enterprise Linux version 6 (RHEL 6). Our Postgres Plus Advanced Server 8.4 and upcoming 9.0 version are also now certified on RHEL6.
So if you’re running RHEL6 and either already using PostgreSQL on other systems or looking to replace a database that hasn’t officially supported RHEL6 yet, you can download our software now and give it a try.
Thanks for your support of PostgreSQL and EnterpriseDB!
RHEL6 Support Now AvailableThis post is the fourth in a series that takes a look at some of the exciting new features of Postgres Plus Advanced Server 9.0, which is currently in beta.
It’s no secret that smart Web companies as well as other modern organizations use distributed memory caching architectures to speed up database response time. The most common piece of software utilized is memcached, although other similar technologies exist.
One of the high-performance additions offered in Postgres Plus Advanced Server is Infinite Cache, which is a more flexible, more feature rich, and easier-to-use distributed caching solution than memcached. An Infinite Cache setup allows database systems to access cache memory outside the physical database server by accessing memory caches on other machines that are in the database server’s network. The end result is that a greater amount of overall memory is made available to a database, which results in an entire database being cached in many cases. Naturally, such a thing has the potential to result in much faster response times for database queries and DML work.
Does Infinite Cache really work? In short, yes it does. The example below (obtained via the pgbench utility) shows the TPS benefits derived from using Infinite Cache for various workloads that include a 4-node Infinite Cache configuration:
One of the drawbacks of various memcached-styled configurations, including 8.4 and earlier versions of Infinite Cache, is that any new machines that are added to the overall configuration result in the entire cache having to be reset. This can be problematic because applications that depend on 24×7 fast query response times experience a performance disruption in their system as the cache ‘warms’ back up.
In Postgres Plus Advanced Server 9.0, Infinite Cache has been enhanced to greatly minimize this situation. In 9.0, when a new node is added to an Infinite Cache configuration, only part of the cache is flushed and must be “re-warmed”. The percentage of the cache that needs to be re-populated depends on how many nodes exist in the current configuration (the more nodes that currently exist, the less cache that needs re-populating). As an example, in a 4-node Infinite Cache configuration, if a 5th node is added, 80% of the cache is retained, whereas prior to 9.0, all of it would be lost.
Try out the new Infinite Cache in Postgres Plus Advanced Server 9.0 now. We’ve just released Beta 4, which will be our last beta before our RC and GA builds. Be sure to let us know what you think via our 9.0 Beta forum.
Thanks, as always, for your support of PostgreSQL and EnterpriseDB!
Postgres Plus Advanced Server 9.0 Sneak Peek – New Infinite CacheOne of the things I enjoy most is visiting customers and getting feedback both on how they’re using our Postgres Plus products today and what their needs will be in the future. A company I visited a couple weeks ago is producing some really powerful software for law enforcement, and it’s really cutting edge stuff. The staff is very savvy and technically sophisticated in how they use technology to accomplish their goals.
They’re also very much an HP shop and have nothing but praise for their HP hardware and the support they receive from HP. But they also use Oracle for a lot of things, and needless to say, they are not pleased with Oracle’s decision to drop support (both Oracle and MySQL) for HP-UX/Itanium. They have no plans to move off their well-running HP hardware and, therefore, are looking for a good database alternative to Oracle.
You may have already seen our press release on EnterpriseDB’s support for the HP Itanium/HP-UX platform, but if not, then let me be the first to bring you up to speed. We’ve ported our Postgres Plus database products to the HP-UX platform, and the betas are now available for you to try out.
Like the company mentioned above, there are many companies and organizations that have no plans to move off their HP hardware. But these modern businesses also want and need an enterprise-class database that gives them Oracle capabilities and support.
With EnterpriseDB’s Postgres Plus Advanced Server, they get just that: a proven, high-performance database server that also has robust Oracle compatibility and PL/SQL support. This means existing Oracle-driven applications can be aimed at Postgres Plus Advanced Server and run with little-to-no application changes being necessary.
Getting Postgres Plus Advanced Server up and running on an HP-UX machine is a piece of cake. If you’ve had to suffer through complicated and error-prone database installs from other vendors in the past on HP boxes, you’ll happily find our install very straightforward and easy to use. In fact, here’s the output from the whole install process on HP:
aps16-249# ./ppasmeta-9.0.4.8-hpux.run Language Selection Please select the installation language <others included but not listed> Please choose an option [1]: ----------------------------------------------------------------------- Welcome to the Postgres Plus Advanced Server Setup Wizard. This is a public beta
test build intended for testing only. NOT FOR PRODUCTION USE. If you have any issues or problems to report, please visit: http://forums.enterprisedb.com ----------------------------------------------------------------------- Please read the following License Agreement. Do you accept this license? [y/n]: y ----------------------------------------------------------------------- User Authentication This installation requires a registration with EnterpriseDB.com. Email [umair222@hotmail.com]: Password : ----------------------------------------------------------------------- Please specify where Postgres Plus Advanced Server will be installed. Installation Directory [/opt/PostgresPlus/9.0AS]: -------------------------------------------------------------
Select the components you want to install. Database Server [Y/n]: y Connectors [Y/n]: y Is the selection above correct? [Y/n]: y ----------------------------------------------------------------------- Additional Directories Please select a directory under which to store your data. Data Directory [/opt/PostgresPlus/9.0AS/data]: Please select a directory under which to store your Write-Ahead Logs. Write-Ahead Log (WAL) Directory [/opt/PostgresPlus/9.0AS/data/pg_xlog]: ----------------------------------------------------------------------- Configuration Mode Postgres Plus Advanced Server always installs with Oracle(R) compatibility
features and maintains full PostgreSQL compliance.
Configuration Mode [1] Oracle Compatible [2] PostgreSQL Compatible Please choose an option [1]: ------------------------------
Please provide a password for the database superuser (enterprisedb). Password : Retype Password : --------------------------------------------------------------------- Additional Configuration Please select the port number the server should listen on. Port [5444]: Select the locale to be used by the new database cluster. Locale [1] [Default locale] <others included but not listed> Please choose an option [1]: Install sample tables and procedures. [Y/n]: y ----------------------------------------------------------------------- Dynatune Dynamic Tuning: Server Utilization Please select the type of server to determine the amount of system resources that may be utilized: [1] Development (e.g. a developer's laptop) [2] General Purpose (e.g. a web or application server) [3] Dedicated (a server running only Postgres Plus) Please choose an option [2]: ----------------------------------------------------------------------- Dynatune Dynamic Tuning: Workload Profile Please select the type of workload this server will be used for: [1] Transaction Processing (OLTP systems) [2] General Purpose (OLTP and reporting workloads) [3] Reporting (Complex queries or OLAP workloads) Please choose an option [1]: ---------------------------------------------------------------------- Pre Installation Summary Following settings will be used for installation: Installation Directory: /opt/PostgresPlus/9.0AS Data Directory: /opt/PostgresPlus/9.0AS/data WAL Directory: /opt/PostgresPlus/9.0AS/data/pg_xlog Database Port: 5444 Database Superuser: enterprisedb Operating System Account: edb Database Service: ppas-9.0 Press [Enter] to continue: ----------------------------------------------------------------------- Setup is now ready to begin installing Postgres Plus Advanced Server on your computer.
Do you want to continue? [Y/n]: y ----------------------------------------------------------------------- Please wait while Setup installs Postgres Plus Advanced Server on your computer. Installing Postgres Plus Advanced Server 0% ______________ 50% ______________ 100% ######################################## Installing Database Server .... Installing Connectors ... # ----------------------------------------------------------------------- Setup has finished installing Postgres Plus Advanced Server on your computer.
.
Pretty easy, eh?
If you’re running HP/Itanium and are interested in a proven database alternative to Oracle, we invite you to download Postgres Plus Advanced Server and give it a try. And please be sure to let us have feedback on your experience. You can also visit our HP-UX page on our website for more information.
Thanks, as always, for your support of PostgreSQL and EnterpriseDB.
Postgres Plus Betas Now Ready for HP-UX PlatformFirst, OK, yeah I know … this is the third blog entry in a row on our site about PostgreSQL being mentioned in an tech article. But I thought it was important to call out for two reasons. One, it’s in CIO magazine which is meaningful because it shows how PostgreSQL has worked itself to the top of the food chain in IT organizations. And two, the article presents a nice case study of a state government agency that demonstrates the industrial-strength capabilities of PostgreSQL:
“The court system in the US state of Wisconsin is using some 100 PostgreSQL databases for the core application used by 72 county circuit courts. About 3000 users directly connect to the production databases in the various court houses and there are dozens of Web applications receiving millions of hits each day.”
Not too shabby, eh?
PostgreSQL 9.1 in CIO MagazineIn case you missed it, Database Journal had a nice article on the PostgreSQL 9.1 beta. What I liked in particular was that Josh not only called attention to the great new 9.1 synchronous enhancement, but also mentioned the transactional control that can be used with it. This is, in my opinion, quite significant as the major knock any synchronous replication system gets is the performance penalty that normally comes along for the ride. But with PostgreSQL synchronous replication, a DBA or developer has very granular control over what can get synchronously replicated. If desired, any transactions that need to be synchronously replicated can be prefaced with a set synchronous_replication = on command, and only those transactions will be handled in that fashion (with everything else being done asynchronously if that’s how things have been set up globally). Very nice!
Download the new 9.1 beta and give synchronous replication (along with everything else) a try and let us know what you think.
PostgreSQL 9.1 Article on Database JournalThis post is the third in a series that takes a look at some of the exciting new features of Postgres Plus Advanced Server 9.0, which is currently in beta.
Before I came to EnterpriseDB, I was the director of product management for MySQL. During my five or so years at MySQL, I saw a lot of interest in companies wanting to either move to an open source database alternative, or use a hybrid approach to data management where a proprietary database would be used for part of the functionality in an application and an open source database would be utilized for a different set of functionality in the same system.
Interestingly, when I polled our customer base year after year and asked what database they were moving from, the number one reply wasn’t Oracle (it was number two). It was Microsoft. For a variety of reasons, people were looking to move away from SQL Server to another database. For those who are looking to either move from SQL Server or use SQL Server in conjunction with a lower-cost database alternative, we’ve just made that easier in our upcoming version of Postgres Plus Advanced Server 9.0.
One of the solutions we bundle with Advanced Server is xDB Replication Server, which is a point-and-click replication solution that provides very flexible and powerful options for replicating from PostgreSQL to PostgreSQL and from Oracle to PostgreSQL. New in 9.0 is the ability to replicate straight from Microsoft SQL Server to PostgreSQL.
The xDB Replication Server is an asynchronous, master-to-slave replication system enabling the easy creation of a variety of replication topologies. From a global perspective, xDB is architected to manage replication in a publish-subscribe manner. The data to be made available for copying is made public as a publication. A publication is defined as a named set of tables and views within a source database. The database that contains the publication is called the publication database of that publication.
To get a copy of that data, a DBA or developer must subscribe to the publication. A subscription is a named association with a publication. Along with its association with a publication, a subscription is associated with a destination database to which the publication is to be copied. This database is called the subscription database. The subscription tables are the tables in the subscription database where each subscription table is created from a corresponding table or view in the publication.
New in xDB is the ability to have Microsoft SQL Server act as a publication datasource. A DBA or developer adds a publication database by supplying xDB with the hostname, port number, security credentials, and database on the source Microsoft SQL Server database, and it is added as an xDB publication source.
Once the SQL Server database is added as a publication, the DBA or developer then selects the option to create a new publication. The xDB Replication Server queries the SQL Server database data dictionary and lists the available tables in the database. One or more tables are then chosen by the DBA and a new publication is created.
The next step is for the DBA or developer to create a PostgreSQL subscription target for the new SQL Server publication. This is accomplished by supplying xDB with the host, database, and login information for the target PostgreSQL server. Once this has been done, a snapshot task is performed to initialize the PostgreSQL server from the SQL Server source, which involves making a copy of the entire SQL Server table(s) and porting it to PostgreSQL. From that point, a schedule can be set up to perform either an entire refresh of the table or to only synchronize the PostgreSQL table with changes that occur to the published table on the SQL Server system.
If you’re interesting in replicating data from SQL Server to PostgreSQL, you can download the beta of Postgres Plus Advanced Server 9.0 now and try the latest version of xDB out for yourself. And please let us know what you think of the new functionality and other enhancements in 9.0.
Thanks, as always, for your support of PostgreSQL and EnterpriseDB!
Postgres Plus Advanced Server 9.0 Sneak Peek – SQL Server ReplicationThis post is the second in a series that takes a look at some of the exciting new features of Postgres Plus Advanced Server 9.0, which is currently in beta.
Tom Kyte is perhaps the best known Oracle expert in the industry. In his book, “Effective Oracle by Design”, Tom has a chapter devoted to the topic of building a performance troubleshooting toolkit. In it, Tom makes the following comments regarding the absolute necessity of being able to analyze and profile database code:
“A source code profiler … can, in minutes, pinpoint that section of code that deserves your undivided attention for an afternoon of tuning. Without it, you could spend a week trying to figure out where you begin to look … I don’t see how you can do this testing and tuning without using a profiler!” (emphasis mine)
Kyte is right. What do you do when a stored procedure that is hundreds or thousands of lines long takes much longer to run than desired? Where do you begin to look? And how about when a database job that consists of four stored procedures, each thousands of lines long, now crosses the finish line in about two hours when it used to take only 15 minutes to complete?
The only way you can quickly identify the bottlenecks in such situations is with a database code profiler. And I’m happy to say that, thanks to the work of one of our very talented engineers, Postgres Plus Advanced 9.0 will have a code profiler.
Code profiling is the process of benchmarking the execution of one or more database procedural code units to understand where the time is being spent in terms its execution. Use of profiling helps to answer questions like these:
Without profiling, the answer to the above questions becomes a real guessing game. DBAs and developers will oftentimes insert output statements in their code or instrument it so they can get response time metrics out that will help them troubleshoot performance issues. But such techniques can be time consuming, are hard to do well, plus it’s oftentimes a hunt-and-peck approach. The same isn’t true when a good code profiler is used.
Then there’s the aspect of trending and historical analysis. Nearly every DBA or developer has had the following conversation with someone who is using a database application:
User: Is something wrong with the online Web order system?
DBA: Why do you ask?
User: It’s slow. It’s not as fast as it used to be.
DBA: How much slower is it?
User: <shrugs shoulders>. It’s just not that fast now. At least I don’t think it is.
Code profiling can tackle such a situation and provide real answers. DBAs and application developers can use a code profiler to establish performance baselines that can be used for future comparison. If complaints roll in that performance has supposedly gone downhill, a DBA can quickly profile the code and compare it to a previously established baseline. Once that’s been done, it becomes easy to determine if a problem really exists and what line(s) of code are causing the problem.
h
Users of Oracle’s DBMS_PROFILER will be right at home with Postgres Plus Advanced Server’s code profiler. To profiler one or more stored procedures or functions, all a DBA or developer has to do is:
As an example, if a DBA wanted to profile the following simple stored procedure:
CREATE OR REPLACE PROCEDURE gim_client_rollup2(start_date timestamp without time zone,
end_date timestamp without time zone) AS
CURSOR CUR1 IS
SELECT client_id, action, price, number_of_units
FROM client_transaction
WHERE transaction_comp_timestamp BETWEEN start_date and end_date;
v_client_id numeric;
v_action character varying(10);
v_price numeric(12,2);
v_number_of_units numeric(12,2);
BEGIN
DELETE FROM client_rollup;
INSERT INTO client_rollup
SELECT client_id,
0,
0,
broker_id
FROM client;
OPEN CUR1;
FETCH CUR1 INTO v_client_id, v_action, v_price, v_number_of_units;
LOOP
EXIT WHEN CUR1%NOTFOUND;
IF v_action = 'BUY' THEN
UPDATE client_rollup
SET amount_bought = amount_bought +
(v_price * v_number_of_units)
WHERE client_id = v_client_id;
ELSE
UPDATE client_rollup
SET amount_sold = amount_sold + (v_price * v_number_of_units)
WHERE client_id = v_client_id;
END IF;
FETCH CUR1 INTO v_client_id, v_action, v_price, v_number_of_units;
END LOOP;
CLOSE CUR1;
END
h
To begin a new profiling session, the DBA first starts the profiler and provides a name for the session:
gim=#EXEC dbms_profiler.start_profiler('profile rollup');
hello
After the profiler is started, the procedure being profiled is executed:
gim=# exec gim_client_rollup2('1990-01-01','2011-01-01');
EDB-SPL Procedure successfully completed
Once the procedure is finished, the profiling session is terminated:
gim=#EXEC dbms_profiler.stop_profiler;
h
With the profiling now complete, the DBA can begin to review the statistical output. A number of tables are provided to the DBA that stores output from each profiling session. To see the various profiling sessions that have been run, the following query can be used:
gim=# select * from plsql_profiler_runs; -[ RECORD 1 ]---+----------------------- runid | 2 related_run | run_owner | enterprisedb run_date | 08-APR-11 12:05:35.206 run_comment | profile rollup run_total_time | 102443000 run_system_info | run_comment1 | spare1 |
.
To view core runtime information, a DBA can query the plsql_profiler_data table:
gim=# select * from plsql_profiler_data; runid | unit_number | line# | total_occur | total_time | min_time | max_time | -------+-------------+-------+-------------+------------+----------+----------+ 2 | 17950 | 1 | 0 | 0 | 0 | 0 | 2 | 17950 | 2 | 0 | 0 | 0 | 0 | 2 | 17950 | 3 | 0 | 0 | 0 | 0 | 2 | 17950 | 4 | 0 | 0 | 0 | 0 | 2 | 17950 | 5 | 0 | 0 | 0 | 0 | 2 | 17950 | 6 | 0 | 0 | 0 | 0 | 2 | 17950 | 7 | 0 | 0 | 0 | 0 | 2 | 17950 | 8 | 0 | 0 | 0 | 0 | 2 | 17950 | 9 | 1 | 0 | 0 | 0 | 2 | 17950 | 10 | 0 | 0 | 0 | 0 | 2 | 17950 | 11 | 1 | 0.015 | 0.015 | 0.015 | 2 | 17950 | 12 | 0 | 0 | 0 | 0 | 2 | 17950 | 13 | 0 | 0 | 0 | 0 | 2 | 17950 | 14 | 0 | 0 | 0 | 0 | 2 | 17950 | 15 | 0 | 0 | 0 | 0 | 2 | 17950 | 16 | 0 | 0 | 0 | 0 | 2 | 17950 | 17 | 0 | 0 | 0 | 0 | 2 | 17950 | 18 | 1 | 0 | 0 | 0 | 2 | 17950 | 19 | 0 | 0 | 0 | 0 | 2 | 17950 | 20 | 1 | 0 | 0 | 0 | 2 | 17950 | 21 | 0 | 0 | 0 | 0 | 2 | 17950 | 22 | 1 | 34.345 | 34.345 | 34.345 | 2 | 17950 | 23 | 18676 | 0.078 | 0 | 0.016 | 2 | 17950 | 24 | 0 | 0 | 0 | 0 | 2 | 17950 | 25 | 18675 | 33.862 | 0 | 0.063 | 2 | 17950 | 26 | 0 | 0 | 0 | 0 | 2 | 17950 | 27 | 16600 | 30.033 | 0 | 0.063 | 2 | 17950 | 28 | 0 | 0 | 0 | 0 | 2 | 17950 | 29 | 0 | 0 | 0 | 0 | 2 | 17950 | 30 | 0 | 0 | 0 | 0 | 2 | 17950 | 31 | 0 | 0 | 0 | 0 | 2 | 17950 | 32 | 0 | 0 | 0 | 0 | 2 | 17950 | 33 | 2075 | 3.767 | 0 | 0.016 | 2 | 17950 | 34 | 0 | 0 | 0 | 0 | 2 | 17950 | 35 | 0 | 0 | 0 | 0 | 2 | 17950 | 36 | 0 | 0 | 0 | 0 | 2 | 17950 | 37 | 0 | 0 | 0 | 0 | 2 | 17950 | 38 | 0 | 0 | 0 | 0 | 2 | 17950 | 39 | 18675 | 0.343 | 0 | 0.016 | 2 | 17950 | 40 | 0 | 0 | 0 | 0 | 2 | 17950 | 41 | 0 | 0 | 0 | 0 | 2 | 17950 | 42 | 0 | 0 | 0 | 0 | 2 | 17950 | 43 | 1 | 0 | 0 | 0 | 2 | 17950 | 44 | 0 | 0 | 0 | 0 | 2 | 17950 | 45 | 0 | 0 | 0 | 0 | (45 rows)
h
A DBA can also join a couple of the DBMS_PROFILER views/tables to see the procedural code with its overall runtime information:
select sourcecode, total_occur, total_time, min_time, max_time from plsql_profiler_data a, plsql_profiler_rawdata b where a.runid = b.runid and a.line# = b.line_number and a.runid = 2;
h
The new DBMS_PROFILER also stores a plethora of runtime diagnostics, including wait information, I/O statistics, and much more:
gim=# select * from plsql_profiler_rawdata where runid=2; -[ RECORD 1 ]----------------------------+--------------- ---------------------------------------- runid | 2 sourcecode | CURSOR CUR1 IS func_oid | 17950 line_number | 1 exec_count | 0 tuples_returned | 0 time_total | 0 time_shortest | 0 time_longest | 0 num_scans | 0 tuples_fetched | 0 tuples_inserted | 0 tuples_updated | 0 tuples_deleted | 0 blocks_fetched | 0 blocks_hit | 0 wal_write | 0 wal_flush | 0 wal_file_sync | 0 buffer_free_list_lock_acquire | 0 shmem_index_lock_acquire | 0 oid_gen_lock_acquire | 0 xid_gen_lock_acquire | 0 proc_array_lock_acquire | 0 sinval_lock_acquire | 0 freespace_lock_acquire | 0 wal_insert_lock_acquire | 0 wal_write_lock_acquire | 0 control_file_lock_acquire | 0 checkpoint_lock_acquire | 0 clog_control_lock_acquire | 0 subtrans_control_lock_acquire | 0 multi_xact_gen_lock_acquire | 0
[AND MANY MORE STATISTICS…]
Without question, Advanced Server 9.0’s new code profiler provides a terrific new window into how your procedural code is executing and performing. You can download the beta of Postgres Plus Advanced Server 9.0 now and try the new code profiler (as well as a number of other new features) out for yourself. And please drop us a line to let us know what you think of the new profiler and other enhancements in 9.0.
Thanks, as always, for your support of PostgreSQL and EnterpriseDB!
Postgres Plus Advanced Server 9.0 Sneak Peek – Code ProfilerThis is the first in a series of “sneak peek’s” at our upcoming Postgres Plus Advanced Server 9.0 release.
About a year or so ago, surveys (done separately) came out from both InformationWeek and TDWI that showed the top reasons IT professionals switched databases. Listed in both surveys as one of the top five reasons for a switch was “poor data load performance”. With the unprecedented growth in data being experienced by nearly all successful businesses, it should come as no surprise that database pro’s are needing to push a lot of data into databases these days, and the faster they get the data in, the faster a company can use that data to make key business decisions.
One of the upcoming enhancements I’m excited about in Postgres Plus Advanced Server 9.0 is our parallel load capability. We’ve provided a load utility (EDB*Loader) that is an improvement over the PostgreSQL COPY command for a while. However, in Postgres Plus Advanced Server 9.0, our talented engineering team has now enhanced it to load a single table in parallel with multiple input files. By simply adding the clause PARALLEL=TRUE, a DBA or developer can initiate multiple sessions and load a table much faster than with the PostgreSQL COPY command or previous versions of the EDB*Loader utility.
Some preliminary testing our team has done highlights the kind of benefits you’ll soon have. The below graph represents the times for loading a 160 million row table using the general PostgreSQL COPY command vs. Advanced Server’s new parallel loader, which was run on a 4-CPU, quad-core, Intel 64-Bit Linux box with 64GB of RAM, half of which was used for a 32GB RAM disk:
Another way to view the same data:
The load time from the community PostgreSQL COPY command goes from 542 seconds to just 87 seconds with a parallel load using 4 sessions. Going from 4 parallel sessions to 8 or 16 saves even more time. The number of MB’s per second increases from 42MB/sec for the PostgreSQL COPY command to 262MB/sec for the parallel load (and up to nearly 400MB/sec with more sessions):
The percentage speedup from the PostgreSQL COPY command equates to an impressive 825% (and up to about 1200% if more sessions are added):
Of course, your mileage will vary depending on your hardware, data, and table structure. But in general, you should experience much faster load times with the new Postgres Plus Advanced Server 9.0 parallel loader.
Another nice enhancement in the EDB*Loader is that it can now load non-empty tables, whereas previous versions could only load – in direct mode – empty tables.
You can download the beta of Postgres Plus Advanced Server 9.0 now and try the new parallel loader (as well as a number of other new features) out for yourself. Be sure to drop us a line and let us know what you think.
Thanks, as always, for your support of PostgreSQL and EnterpriseDB!
Postgres Plus Advanced Server 9.0 Sneak Peek – Parallel Loader
