> I know I need PK to *run* slony, but I also know that loading data first
> and then building an index can run an order of magnitude faster than
> copying into a table with indexes.

I'd go with "binary order of magnitude;" a decimal order of magnitude
would seem to overstate things a bit.

> I think the initial COPY time could be much reduced if done in a similar
> way to what pg_dump does (i.e DROP PK; TRUNCATE TABLE; COPY ; ALTER TBL
> ADD PK)

I would expect that the implementation should ultimately involve DROP ALL
INDICES; TRUNCATE TABLE; COPY; ADD ALL INDICES.

That's sensible to look at for version 1.1; it's a bit much for 1.0.3.

There are two conspicuous "special little things" about how it works now:

1 - As of 1.0.2, it uses DELETE FROM TABLE, because if running on
PostgreSQL 7.3, TRUNCATE is not "transaction safe" and cannot be run
inside a transaction.

In 1.0.3, TRUNCATE is used if possible.

2 - Tables may have _candidate_ primary keys that are not formally defined
as a PK.  Handling of that needs to be different from the handling of a
"honest-to-goodness" PK.