Pervasive Summit PSQL v10
Pervasive Software has a long history – 25 years, in fact, as they’re emphasizing in some current marketing. Ownership and company name have changed a few times, as the company went from being an independent startup to being owned by Novell to being independent again. The original product, and still the cash cow, was a linked-list DBMS called Btrieve, eventually renamed Pervasive PSQL as it gained more and more relational functionality.
Pervasive Summit PSQL v10 has just been rolled out, and I wrote a nice little white paper to commemorate the event, describing some of the main advances over v9, primarily for the benefit of current Pervasive PSQL developers. In one major advance, Pervasive made the SQL functionality much stronger. In particular, you now can have a regular SQL data dictionary, so that the database can be used for other purposes – BI, additional apps, whatever. Apparently, that wasn’t possible before, although it had been possible in yet earlier releases. Pervasive also added view-based security permissions, which is obviously a Very Good Thing.
There also are some big performance boosts. Most of these are via a new module (which Pervasive calls a “driver”) called “Xtreme I/O.” This comes from a company called QuickShift – previously known for Microsoft SQL*Server acceleration — which sold Pervasive the source code and, I presume around the same time, ceased operations.
Xtreme I/O’s biggest virtue is – there’s our theme-of-the-month again – compression. In the case of an OLTP DBMS like Pervasive PSQL, compression helps in two big ways. First, it reduces I/O. Second, it allows more data to be kept in cache, and thus accessed at RAM speed.
PSQL v10 also has two other boosts to in-memory processing. First, it allows 64-bit addressability, and hence access to more RAM. Second, it fixes some prior-version weirdness, and allows a higher fraction of overall RAM to be devoted to cache. Between those enhancements and the compression, the net effect is that you can now put a number of gigabytes of user data into RAM.
So should I categorize Pervasive PSQL as a memory-centric system? Well, if you’re looking at data access methods for memory-centric OLTP processing, linked-list isn’t all that bad. Even so, it would be an exaggeration to say that PSQL is truly optimized for in-memory processing. So no, PSQL is not memory-centric. But even so, it runs at RAM speed for significantly large databases than it did in v9.
One area of advance in PSQL v10 that I resisted covering in the white paper was Microsoft compatibility, be that Vista support, .Net support, or a closer resemblance to SQL*Server functionality. While those are very important, they also are quite boring. I might well change my mind if the SQL*Server resemblance became so close one could swap SQL*Server out for PSQL and have things basically keep running. But I don’t think PSQL is quite at that point yet.
Oh yes — if you do choose to look at Pervasive’s website or other marketing materials, please be aware of one weird choice they made in marketing jargon. They equate “transactional” to linked-list, and hence draw a distinction between “transactional” and “relational.” I’m pretty sure this is just a marketing artifact, and doesn’t actually indicate any severe deficiencies in their SQL transactional capabilities, unless perhaps you’re looking for some kind of distributed two-phase commit capability.
Comments
Leave a Reply