On 2017-05-12 21:56:30 -0400, Robert Haas wrote: > Cheap isn't free, though. It's got a double-digit percentage overhead > rather than a large-multiple-of-the-runtime overhead as triggers do, > but people still won't want to pay it unnecessarily, I think.
That should be partiall addressable with reasonable amounts of engineering though. Efficiently computing the target partition in a hash-partitioned table can be implemented very efficiently, and adding infrastructure for multiple bulk insert targets in copy should be quite doable as well. It's also work that's generally useful, not just for backups. The bigger issue to me here wrt pg_dump is that partitions can restored in parallel, but that'd probably not work as well if dumped separately. Unless we'd do the re-routing on load, rather than when dumping - which'd also increase cache locality, by most of the time (same architecture/encoding/etc) having one backend insert into the same partition. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
