| From: | Віталій Тимчишин <tivv00(at)gmail(dot)com> |
|---|---|
| To: | david(at)lang(dot)hm |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>, Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Slow count(*) again... |
| Date: | 2011-02-04 07:39:38 |
| Message-ID: | AANLkTimju9TDj_YNaFMJzRMDQtmYGC1=mRsci7Mo+yo7@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
4 лютого 2011 р. 09:32 <david(at)lang(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2011-02-04 07:53:55 | Re: exposing COPY API |
| Previous Message | david | 2011-02-04 07:32:47 | Re: [HACKERS] Slow count(*) again... |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2011-02-04 07:59:06 | Re: [HACKERS] Slow count(*) again... |
| Previous Message | david | 2011-02-04 07:32:47 | Re: [HACKERS] Slow count(*) again... |