Does anyone know what substantial differences there are between the regular PostgreSQL and Postgres Plus?
The database is the same, meaning that the SQL is fully compatible to any other PostgreSQL installation around (save for the GIS data formats).
The main difference is that there is a bunch of modules and tools bundled with Postgres Plus that you would have to collect and install separately and by yourself otherwise. Thus the main advantage is easy and speedy installation.
Most of the bundled stuff looks like it's freely available from other sources. That Postgres Studio application looks suspiciously close to pgAdmin III.
One important difference is the licence:
Postgres Plus is only free for "non-production" use.
you can find detailed purchasing options here:
http://www.enterprisedb.com/products/purchase.do
Postgres PLUS is proprietary, PostgreSQL is Open source under permissive license (and that's why Postgres PLUS is proprietary).
Postgres PLUS has support for Oracle PL/SQL, while PostgreSQL does not, at least not officially.
Those are two most obvious differences.
I used 8.2 and when was the time to switch to 8.3 I tried PostGresPlus.
The Speed was a lot faster. LOT I mean queries that took 30 secs, takes now less than 2 seconds. I am not sure if it's 8.3 that is faster or the Enterprise Plus but I can tell you that I was impressed.
Other thing that I like is that I can debug proc stored. It cames with more tools.
Related
I am assembling a Business Intelligence solution using the Pentaho software as a BI engine. Within this solution, I had to set up a requirements for a PostgreSQL database server.
The current situation is very easy, since no ETL process is being carried out for data extraction, so the PostgreSQL configuration has not changed it much, and it is practically as it is configured as "factory".
I would like to know what Postgres configuration parameters have to be touched and modified to optimize it as a Datawarehouse. I have seen a lot of documentation, but it is not clear to me at all, since one documentation says that such values have to be modified, and other documentation, other completely different values.
I would like to know just that, if there is a clearer and more precise documentation to optimize a postgres 9.6 to be used as a Pentaho DW.
Thank you very much
In my system I have all those databases which falls under openerp version 7, 8 and 9. I want to differentiate them and take only those databases which falls under odoo version 8. I have checked in postgres files as well as in .openerp-server file. But I didn't get any thing which can help me. How to differentiate the databases?
AFAIK there is no obvious place in the database to look for that.
It would be possible to write a script that would inspect the data model looking for known differences between versions to detect the corresponding one.
But no such tool exists at the moment.
Personally, I solve this by always including the version number in the database name, such as dev-v8 or dev-v9.
Here is an answer..
You can execute following query :
SELECT * FROM ir_module_module WHERE name='base' AND latest_version like '9.%'
Any idea how to go about doing that through a tool(preferred). Any alternate ways to do that.
You can check out the migration studio from EnterpriseDB here, although I have no experience with it.
There is no comparison to doing it yourself though - if you're not familiar with Postgres then this will get you familiar, and if you are, then aside from the data entry aspect, this should be old hat.
Use maxdb tools to generate a SQL text export of the database. Then import this file in PostgreSQL, luckily you won't need prior processing of the data dump.
I know that Postgres uses MVCC and stores older versions of rows on disk. I would like to access (read-only) some old, discarded versions of a concrete row. How can I do it?
In PostgreSQL 9.1 and later, the best solution for this is https://github.com/omniti-labs/pgtreats/tree/master/contrib/pg_dirtyread which is an extension that provides a functional interface in sql to access old, unvacuumed versions of rows. Other tools may exist for other dbs. This works well for a number of cases data recovery, just exploring the utility of mvcc, and the like. With some effort it might work on earlier versions.
I have a database which is part of a closed system and the end-user of the system would like me to write some reports using the data contains in a Sybase SQL Anywhere Database. The system doesn't provide the reports that they are looking for, but access to the data is available by connecting to this ASA database.
The vendor of the software would likely prefer I not update the database and I am basically read-only as I am just doing some reporting. All is good, seal is not broken, warranty still intact, etc,etc..
My main problem is that I am using jConnect in order to read from the database, and jConnect requires some "jConnect Routines" to be installed into the database. I've found that I can make this happen by just doing an "Alter Database Upgrade JConnect On", but I just don't fully understand what this does and if there is any risks associated with it.
So, my question is does anyone know exactly what jConnect routines are and how are they used? Is there any risk adding these to a database? Should I be worried about this?
If the vendor wants you to write reports using jConnect they will have to allow the installation of the JConnect tables.
These are quite safe, where I work the DBA team install these as a matter of course and we run huge databases in production with no impact.
There is an alternative driver that you could use called jTDS. Its open source and supports MS SQL Server and Sybase. I'm not sure if they require the JConnect tables or not.
I think that the additional tables are a bit of anachronism in this day and age.
Looking at ASA 10 docs, there is another driver: the iAnywhere JDBC driver which seems to be going through the ODBC driver, and as such, probably will not require an alteration of the database.
On the other hand, installing the "jConnect system objects" is done by running the script scrits/jcatalog.sql... You can show it the DBAs, if you want to reassure them. It creates some procedures, tables, variables.
The need for this script probably comes from the fact that jConnect talks to both ASE (Sybase) and iAnywhere databases, so it needs a compatibility layer installed in the database...