Tom,
> [ shrug... ] Everybody in the world is going to want their own little
> problem to be handled in the fast path. And soon it won't be so fast
> anymore. I think it is perfectly reasonable to insist that the fast
> path is only for "clean" data import.
Why?
No, really.
It's not as if we don't have the ability to measure performance impact.It's reasonable to make a requirement that new
optionsto COPY
shouldn't slow it down noticeably if those options aren't used. And we
can test that, and even make such testing part of the patch review.
But ... fault-tolerant COPY is one of our biggest user
requests/complaints. At user group meetings and the like, I get asked
about it probably every third gathering of users I'm at. While it's not
as critical as log-based replication, it's also not nearly as hard to
integrate and review.
I fully support the idea that we need to have the extended syntax for
these new COPY options. But we should make COPY take an alternate path
for fault-tolerant COPY only if it's shown that adding these options
slows down database restore.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
