Bruce Momjian: Postgres Blog

PgLife Averages Thirty Active Users

Mon, 13 May 2013 12:00:00 -0400

A week after the release of PgLife, the site is averaging thirty active users. (I define an active user as an IP address that has viewed the site for at least five minutes during the past hour.) I consider that a success. Since the release of PgLife, I have increased the content update interval and added an About page explaining the site's purpose, which also includes the active user count.

The site uses AJAX, Perl, Procmail rules, and Apache to collect and deliver dynamic content. Recent improvements in the Postgres mailing list archive feature set have made linking to emails much simpler.

PgLife was my first attempt at a dynamic website, and I learned a few things. First, I learned the value of having an alert file that can force a browser reload to push fixes and improvements to the browser. Second, I used the same file to allow pushing of news alerts to users, e.g. 9.3 Beta1. Third, I learned the importance of controlling browser and server caching and revalidation when using dynamic content.

PgLife Is Now Live

Mon, 06 May 2013 12:00:00 -0400

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.

Post a Comment

9.3 Release Notes Ready for Beta

Fri, 03 May 2013 12:00:00 -0400

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

Starting on 9.3 Release Notes

Fri, 12 Apr 2013 12:00:00 -0400

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

Matching Server and Client Constraints

Thu, 11 Apr 2013 12:00:00 -0400

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).

Dynamic Columns

Wed, 10 Apr 2013 12:00:00 -0400

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.

Pg_Upgrade Now Handles Invalid Indexes

Tue, 09 Apr 2013 12:00:00 -0400

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

Twenty-One Hours to Exploit

Mon, 08 Apr 2013 12:00:00 -0400

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.

View or Post Comments

Partial Indexes

Mon, 08 Apr 2013 12:00:00 -0400

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

Expression Indexes

Sat, 06 Apr 2013 12:00:00 -0400

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));