Kris Deugau wrote > David G Johnston wrote: >> Going from recent memory this particular behavior complaint has now come >> up >> three times in the past six months - the main complaint previously is >> that >> given an insert trigger for the partition you have to copy, not move, the >> insert to the child tables - leaving the parent table populated during >> the >> insert and thus returning the count - and then delete the record from the >> parent table. That sequence, while solving the row number problem, then >> causes vacuum to behave undesirably. > > Eugh. For the (mostly) one-off bulk-copy process I've been preparing I > have a couple of other workarounds (simplest being just inserting in the > child table directly), but if it comes down to it it will be simpler to > put up with the relatively minor nuisance of staying unpartitioned > rather than (potentially) destabilizing someone else's code. After all, > I've already written the code to archive old records from the > unpartitioned table anyway... it just would have been nice to be able > to "pg_dump dbname -t table_2013" instead.
The specific thread I was thinking of is here: http://postgresql.nabble.com/Autovacuum-on-partitioned-tables-in-version-9-1-td5826595.html The links referenced there provide the basis for my thought that there might be 3 recent examples... David J. -- View this message in context: http://postgresql.nabble.com/INSERT-to-partitioned-table-doesn-t-return-row-count-tp5829148p5829163.html Sent from the PostgreSQL - general mailing list archive at Nabble.com. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
