EnterpriseDB: Memory Management & Performance
Oracle Tips by
management is tightly coupled with performance. While
performance can be impacted by design and internals such as locking
mechanisms, without appropriate memory management, performance will
most items in the comparison between EnterpriseDB and Oracle, Oracle
provides more functionality at the cost of complexity. You can
tweak many of the EnterpriseDB memory parameters if you have time to
play with them. In reality, you need only set a single parameter
(edb_dynatune, Chapter 2) and EnterpriseDB will do the rest.
possible to install Oracle and accept default memory configurations.
I can honestly say that I have never seen a production instance that
was configured that way. Usually 8-10 configuration parameters
must be tweaked for individual installations.
used to be many more parameters that needed to be tweaked.
Recent versions of Oracle have simplified this step dramatically.
Configure several buffers and set some maximum and minimum memory
limits and the database is ready to go.
memory structures are somewhat of an arcane science to most people but
those memory structures are really very standard and are based on
generally accepted theory and, at least conceptually, is not that
different between database vendors.
Non-memory related performance is also fairly standardized. The
rule in a database to increase performance is to decrease locking and
IO. EnterpriseDB inherits one of the most advanced locking
mechanisms, the multi-version concurrency control or MVCC.
and EnterpriseDB use the same locking model (via different
implementations) so that a reader does not wait for a writer and a
writer does not wait for a reader. Different database sessions
may see a different version of the data depending on the operations
being performed on that data.
users know about rollback segments and/or undo space. MVCC is
much the same in concept. EnterpriseDB undo is "cleaned up" in a
process called vacuuming while Oracle's undo is performed in another
tablespace and is maintained in parallel. The result is the
same: highly efficient locking.
benefit of MVCC is the ability to perform hot backups on your data.
Because each session will get its own version of the data should it
need it (to maintain consistency), hot backups are feasible.
Performance having to do with IO will be the same between EnterpriseDB
and Oracle. All database applications need to be analyzed and
designed to make the best trade-offs between IO and overhead.
Decisions such as indexing and data relationships are the same for
most any database.
professionals currently working with Oracle will have no problems
understanding, configuring or troubleshooting memory and performance
issues within EnterpriseDB. The similarities between Oracle and
EnterpriseDB are impressive.
is the king of availability. From RAC to Data Guard to Streams,
currently holds the crown of availability. EnterpriseDB does not
provide the feature set of availability that Oracle does.
compete in the replication arena though. With add-ons such as
Slony I and II for EnterpriseDB to and from EnterpriseDB/PostgreSQL
providing much of the same functionality as Streams Replication and
Data Guard and the EnterpriseDB Replication Console providing data
migration between Oracle and EnterpriseDB, EnterpriseDB is a highly
implementation of the availability is primarily via replication.
Replication, while fairly simple to configure, is different from
Oracle replication. Database professionals should not have a
problem understanding, configuring or troubleshooting EnterpriseDB
replication. EnterpriseDB replication is covered in detail in
reliability of EnterpriseDB is truly enterprise-class.
PostgreSQL has been around for 20 years and has been considered a
reliable production class database for 10. Past performance is
the best indicator of future performance.
is an excerpt from the book "EnterpriseDB:
The Definitive Reference" by Rampant TechPress.