Re: COPY Hacks (WAS: RE: Postgresql vs SQLserver for this application ?)
В списке pgsql-performance по дате отправления:
| От | Harald Fuchs |
|---|---|
| Тема | Re: COPY Hacks (WAS: RE: Postgresql vs SQLserver for this application ?) |
| Дата | |
| Msg-id | puwtreg4ke.fsf@srv.protecting.net обсуждение исходный текст |
| Ответ на | RE : RE: Postgresql vs SQLserver for this application ? (bsimon@loxane.com) |
| Список | pgsql-performance |
In article <1112813199.42542e8f17b4d@webmail.telus.net>, Mischa <mischa.Sandberg@telus.net> writes: > This thread seems to be focusing in on COPY efficiency, > I'd like to ask something I got no answer to, a few months ago. > Using COPY ... FROM STDIN via the Perl DBI (DBD::Pg) interface, > I accidentally strung together several \n-terminated input lines, > and sent them to the server with a single "putline". > To my (happy) surprise, I ended up with exactly that number of rows > in the target table. > Is this a bug? Is this fundamental to the protocol? > Since it hasn't been documented (but then, "endcopy" isn't documented), > I've been shy of investing in perf testing such mass copy calls. > But, if it DOES work, it should be reducing the number of network > roundtrips. > So. Is it a feechur? Worth stress-testing? Could be VERY cool. Using COPY from DBD::Pg _is_ documented - presumed you use DBD::Pg version 1.41 released just today.
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера