On 10/4/2004 7:51 AM, cbbrowne at ca.afilias.info wrote:

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

The problem with this is that "drop index and recreate later" is easily 
said, but hard to implement correctly. What if the index is in reality a 
unique key constraint? Just recreating the index doesn't restore the 
constraint entry and the dependency records. And if that unique 
constraint is required to satisfy foreign key constraints on other 
tables, then you'd have to save those too for later recreation.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #