Re: [HACKERS] Slow count(*) again...

Поиск
Список
Период
Сортировка
От Віталій Тимчишин
Тема Re: [HACKERS] Slow count(*) again...
Дата
Msg-id AANLkTimju9TDj_YNaFMJzRMDQtmYGC1=mRsci7Mo+yo7@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Slow count(*) again...  (david@lang.hm)
Список pgsql-performance


4 лютого 2011 р. 09:32 <david@lang.hm> написав:


when a copy command is issued, I assume that there is some indication of how much data is going to follow. I know that it's not just 'insert everything until the TCP connection terminates' because that would give you no way of knowing if the copy got everything in or was interrupted part way through. think about what happens with ftp if the connection drops, you get a partial file 'successfully' as there is no size provided, but with HTTP you get a known-bad transfer that you can abort or resume.

I don't think so, since you can do 'cat my_large_copy.sql | psql'. AFAIR it simply looks for end of data marker, either in protocol or in stream itself (run copy from stdin in psql and it will tell you what marker is). 



--
Best regards,
 Vitalii Tymchyshyn

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

Предыдущее
От: david@lang.hm
Дата:
Сообщение: Re: [HACKERS] Slow count(*) again...
Следующее
От: Віталій Тимчишин
Дата:
Сообщение: Talking about optimizer, my long dream