The Build

15 February 2011


“10 Easy Ways to Destroy Performance” at pgDay at SCALE-9X

I’ll be presenting a talk on “10 Easy Ways to Destroy Performance” at pgDay at SCALE-9X, on February 25th in Los Angeles.


“Django Development with PostgreSQL” at PostgreSQL Conference East

I’ll be presenting a full-day tutorial on Django Development with PostgreSQL at PostgreSQL Conference East, March 22-25 in New York!

4 February 2011


PostgreSQL for Servoy Developers

The slides from my presentation on PostgreSQL for Servoy Developers, presented at ServoyWorld 2011, are available here.

31 December 2010


Nobody Here But Us Chickens: Google and Lies We Tell Ourselves

tl;dr: If you make a tradeoff, be honest about it. Don’t lie to yourself that you are making a positive architectural decision when you make a negative tradeoff.

Read the rest of this entry »

22 December 2010


Extra columns when doing .distinct() in a Django QuerySet

tl;dr: If you are doing a .distinct() query and limiting the results using .values() or .values_list(), you may be in for a surprise if your model has a default ordering using the Meta value ordering. You probably want to clear the ordering using .order_by() with no parameters.

Read the rest of this entry »


Getting the ID of Related Objects in Django

tl;dr: Don’t retrieve a whole row just to get the primary key you had anyway. Don’t iterate in the app; let the database server do the iteration for you.

Read the rest of this entry »

17 December 2010


Why I run qmail

There’s a very nasty root exim exploit in the wild.

Updated: To be fair to the hard-working exim team, this bug was fixed some time ago.


Comparing NULLs Considered Silly

tl;dr: You can’t compare NULLs. A nullable primary key is a contradiction in terms. You can’t join on NULL, so a NULL foreign key refers to nothing, by definition. NULL doesn’t do what you think it does, no matter what you think it does.

Read the rest of this entry »

14 December 2010


Using Server-Side PostgreSQL Cursors in Django

This is a follow-up to the previous post, in which we talked about ways of handling huge result sets in Django.

Two commenters (thanks!) pointed out that psycopg2 has built-in support for server-side cursors, using the name option on the .cursor() function.

To use this in Django requires a couple of small gyrations.

First, Django wraps the actual database connection inside of the django.db.connection object, as property connection. So, to create a named cursor, you need:

cursor = django.db.connection.connection.cursor(name='gigantic_cursor')

If this is the first call you are making against that connection wrapper object, it’ll fail; the underlying database connection is created lazily. As a rather hacky solution, you can do this:

from django.db import connection

if connection.connection is None:
    cursor = connection.cursor()
       # This is required to populate the connection object properly

cursor = connection.connection.cursor(name='gigantic_cursor')

You can then iterate over the results using the standard iterator or cursor.fetchmany() method, and that will grab results in from the server in the appropriate chunks.

13 December 2010


Very Large Result Sets in Django using PostgreSQL

tl;dr: Don’t use Django to manage queries that have very large result sets. If you must, be sure you understand how to keep memory usage manageable.

Read the rest of this entry »

« Older Entries

Newer Entries »