Let’s start with slashing database costs by over 90 percent, a scenario documented by a division within the federal government that is charged with evaluating enterprise technologies.

This particular client was exploring a cost-efficient solution for one of its organizations that needed to cut costs but not adversely affect its mission, which meant finding an open source database solution with equivalent or better features than its current, money-eating solution. After evaluating a few alternatives, including MySQL and Oracle, the organization conducting the study found that EnterpriseDB’s Postgres Plus Advanced Server provided the best performance while significantly cutting costs. When comparing Postgres Plus Advanced Server to Oracle, there was a staggering cost reduction of over 90 percent. Our solution also significantly ranked better on cost and performance than MySQL and a couple of other open source solutions.

We have other terrific stories to tell in the government sector, though as those of you who do business with the feds know well, naming the actual characters is rarely possible. There are a couple of agencies frequently referenced as PostgreSQL users, such as the Federal Aviation Administration (FAA), the US State Department and the National Weather Service. Suffice to say there are plenty of agencies that use PostgreSQL, many of which look to us to provide support and training for their deployments of community PostgreSQL or our own Postgres Plus Advanced Server.

New Postgres users are often confused by the variety of activities in the Postgres community. Even us old-timers can be overwhelmed in monitoring the Postgres community. To meet these two needs, I have created a website called PgLife which dynamically displays the current activity in each of the community areas: email, development, blogging, media, news, events, and IRC chat. I am hopeful people will find this useful in understanding the
Postgres community, and in increasing their involvement.

I have completed the 9.3 release notes so they are ready for beta release. They will be regularly updated until 9.3 final.

Post a Comment

With our final 9.3 commit-fest almost complete, and few 9.3 open items, I have been asked to start on the 9.3 release notes. I have blogged about
this process in the past (1, 2), so I will not bore you with the details. I expect to be done in a week.

Post a Comment

Postgres supports all the SQL-standard constraint types, e.g. UNIQUE, CHECK. These work fine at the server level:

CREATE TABLE ledger (id SERIAL, balance NUMERIC(10,2) CHECK (balance > 0));

INSERT INTO ledger VALUES (DEFAULT, -2.00);
ERROR:  new row for relation "ledger" violates check constraint "ledger_balance_check"
DETAIL:  Failing row contains (1, -2.00).

Continue Reading »

SQL has never been good at handling dynamic columns ? it can easily process tables with a fixed number of columns, but dynamic column handling has always been a challenge. (Dynamic columns are often used to implement user-defined fields.) One approach has been to define columns for every possible value that might be stored in a row; this leads to sparse tables containing mostly NULL values. Because Postgres stores NULL values in a single bit, there is little overhead to this approach. However, it is hard to call these dynamic columns since every new column requires an ALTER TABLE … ADD COLUMN command.

Another approach is to use entity/attribute/value layout, where each value is stored in its own row. This obviously increases storage requirements, has performance challenges, and adds complexity to SQL queries.

Fortunately, Postgres has various options to efficiently handle dynamic columns. The simplest solution is arrays which allow multiple values of the same data type to be stored in a single field. This assumes that the values are independent, or that their ordinal position in the array is sufficiently meaningful.

Continue Reading »

In December, I reported that a bug had been discovered in how pg_upgrade handled invalid indexes, and that the next release of pg_upgrade
would throw an error if invalid indexes were found; that release happened in February. In an easily-overlooked development, last week’s
security release changed pg_dump so it now skips dumping invalid indexes. This allows the most recent version of pg_upgrade to upgrade clusters with invalid indexes, rather than throwing an error.
Post a Comment

Having covered expression indexes, I want to cover another index feature - partial indexes. Partial indexes allow you to create an index on part of a table. Why would you want to do that -

• index only frequently-accessed values, allowing smaller index files
• avoid indexing common values, which are unlikely to be useful in an index
• smaller index files allow faster index traversal and improve index caching
• avoid index insertion overhead for non-indexed values
• constrain uniqueness to a subset of table rows

People usually don’t use expression or partial indexes initially, but there are certainly some use-cases that can only be solved with these index features.

View or Post Comments

You probably heard about the important Postgres security releases (FAQ) last week, but maybe you thought it was mostly a theoretical threat. Well, the Schemaverse game author left a non-upgraded server open to the Internet to see how long it would take to be infected – turns out it took a sobering
21 hours. Hopefully this gets everyone’s attention on the need to upgrade.

Post a Comment

Having covered virtual columns recently, I wanted to cover one additional type of stored value, expression indexes. Unlike virtual columns, which are computed on each access, expression indexes are stored in index files, allowing rapid access. Let’s look at some examples, building on the customer table and fullname function created in my previous blog entry:

CREATE INDEX i_customer_lastname ON customer (lastname);

CREATE INDEX i_customer_concat ON customer ((firstname || ' ' || lastname));

CREATE INDEX i_customer_fullname ON customer (fullname(customer));

Continue Reading »