Thomas, > I forgot to mention that I'm running 7.4.6. The README includes the > caveat that pgmemcache is designed for use with 8.0.
Well, you could always hire Sean to backport it. > 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. What other operations are ocurring on the table concurrent with the COPY? Copy isn't really intended to be run in parallel with regular insert/update on the same table, AFAIK. > 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. Alternately: bulk load the new rows into a "holding" table. Do counts on that table. Then, as one transaction, drop the triggers, merge the holding table with the live table and update the counts, and restore the triggers. Alternately: Move the copy out of triggers into middleware where you can deal with it more flexibly. Alternately: Resign yourself to the idea that keeping running statistics is incompatible with doing a fast bulk load, and buy faster/better hardware. -- 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