As far as dropping/recreating triggers, there seem to be two strategies:

1. Perform the drop-import-create operation in a transaction, thereby guaranteeing the accuracy of the counts but presumably locking the table during the operation, which could take many minutes (up to an hour or two) in extreme cases.

2. Drop the triggers, import, create the triggers, and update with the import count, recognizing that other updates could've occurred without accumulating updates during the import process, then later (nightly, maybe?) do a full update to recalibrate the counts. In this case the count( * ) involved could also lock the table for a bit pending the sequential scan(s) if the update is performed in a transaction. Otherwise, again, there is a realistic possibility of inaccurate counts occurring and persisting between calibrations.

Is there a best practice anywhere here?

-tfo

--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005

On Jan 27, 2005, at 11:41 PM, Josh Berkus wrote:

Thomas,

Would it be absurd to drop the triggers during import and recreate them
afterward and update the counts in a summ> ary update based on
information from the import process?

That's what I'd do.

--
--Josh

Josh Berkus
Aglio Database Solutions
San Francisco


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
     joining column's datatypes do not match

Reply via email to