On Tue, 27 Oct 2009, Alvaro Herrera wrote:
Now 40 mins walking those pages to figure out that they need to be truncated, I concede that it's too much. Maybe we shouldn't be doing a backwards scan; perhaps this breaks the OS readahead and make it even slower.
I've watched that take hours before on a large table after purging hundreds of gigabytes of old historical data. Improvements to speed that up like scanning more efficiently would be welcome. But given the potential for a really bad worst-case here, I have to wonder if this really needs to get broken up into bits with finer locking instead of micromanaging the details.
(Yes, I should have been using date-range partitioning instead and just dropped the old partitions, but sometimes these things grow only after you've made design decisions the wrong way)
-- * Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
