Saturday, January 13, 2007

Table Formatting in Blogger

I'm pretty new to Blogger but one of the first snags I hit was with formatting tables due to the way Blogger automatically inserts line breaks. You can disable that behavior under Settings but it's a global option so it affects all posts. Another option is to write your tables without line breaks, but that's a maintenance problem.

Here's another approach that works (tested with Firefox 1.5 and IE 6; anyone have other browser results?). At the top of your post add this:

<style type="text/css">.nobr br { display: none }</style>

Then place your table within that class:
<div class="nobr">
<table border="1">
That has the effect of turning off the display of the Blogger-generated line breaks within the div, causing the table to be rendered properly.

Here's how that table looks in your browser:

GOOG 505.00 2006-01-12
BRK-A 110,000.00 2006-01-12

I think it should be possible to move the CSS declaration into the template so you don't have to repeat it in each post.

Note from reader S.B.:
Unfortunately, both the "Compose" and "Preview" views of a post still render incorrectly, but when you actually publish, the table does come out right!

Sunday, January 7, 2007

Postgresql Performance Tips for Data Loads

  • Turn off fsync in postgresql.conf. This can make a huge difference.

  • Temporarily disable triggers.

    Postgresql 8.x supports an ALTER statement:


    With Postgresql 7.x you need to modify the system tables directly:
    UPDATE pg_class
    SET reltriggers = 0
    WHERE relname = 'foo';
    To re-enable:
    UPDATE pg_class
    SET reltriggers = (
    SELECT count(*)
    FROM pg_trigger
    WHERE pg_class.oid = tgrelid
    WHERE relname = 'foo';
  • Postgresql docs on efficient data loads

Saturday, January 6, 2007

Creating a Postgresql Development Database

Notes on how to restore a Pg database for a dev environment to make it simple to create additional copies or revert back to the production schema.

Drop and restore your db from a recent backup. Include a datestamp in the database name to keep track of the version you're restoring from. The specifics of this commands will vary depending on your permissions, backup method, etc.

$ dropdb mydevdb_20070106
$ createdb -U postgres -E LATIN1 mydevdb_20070106
$ pg_restore -U postgres -d mydevdb_20070106 ~/db-backup.2007-01-06

If you're restoring from production data, be sure to munge it at this point to remove all valuable/sensitive information, and delete the backup file so your dev environment isn't a target.

Now with this restored version of the database you can create any number of additional copies to actually work on. Leave the initial restore untouched so you can always revert back to it.

$ psql mydevdb_20070106
mydevdb_20070106=# CREATE DATABASE mydevdb WITH TEMPLATE mydevdb_20070106;
mydevdb_20070106=# CREATE DATABASE toms_devdb WITH TEMPLATE mydevdb_20070106;