Executive summary: Why would the TOAST table on the slave have 4x the page count of the master? Is there a way to compact it if I don't have enough disk space to duplicate the table? How do I prevent this situation from recurring? On Wed, Mar 14, 2012 at 7:38 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: > > The good news is that if the table is > bloated, it should be able to just write to the free space in the > table that's already there. Thank you, I got it. The table is not bloated, as per check_postgres.pl --action=bloat I compared number of pages on the large table between the Slony origin node and the slave, using "SELECT relname, relpages FROM pg_class" origin: 386,918 slave: 421,235 origin toast: 19,211,059 slave toast: 70,035,481 How about that? reltuples on origin toast table: 6.76368e+07 reltuples on slave toast table: 7.00354e+07 Here is my situation: 1. I've got an 800 GB (not TB as I wrote earlier today) filesystem. 2. 595 GB is in use by the Postgres database, and over 527 GB by this large table (including TOAST) 3. 155 GB is free. 4. pg_dump of this large table comes out to 212 GB in size (so physical size is nearly 3x the logical size) Why does the slave TOAST table have 4x the page count of the master? Best, Aleksey -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
