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.