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
