Re: COPY enhancements

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: COPY enhancements
Дата
Msg-id 4AAD617F.2070104@agliodbs.com
обсуждение исходный текст
Ответ на Re: COPY enhancements  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: COPY enhancements  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Rough draft: easier translation of psql help
Следующее
От: Tom Lane
Дата:
Сообщение: Re: COPY enhancements