On Tue, Nov 28, 2006 at 07:34:56PM +0200, Andrus wrote:
> This id good idea but it forces to use Postgres protocol for downloading.
Why, of course.
> This protocol has some timeouts which are too small for large file download.
For "sane" values of "large" I doubt this is true. A field
in PG can store about 1 GB of data (says the FAQ) and the
protocol better be able to hand out as much.
It may be that you need to increase statement_timeout -
which can be done on a per-session basis.
> Postgres protocol has also a lot of overhead added to downloadable data.
Yes. But you wanted to use port 5432 on a machine already
running PG.
Not sure but using a binary cursor might improve things.
Using a client library capable of the v3 (?) protocol should
significantly lower the overhead, too.
> It also requires that whole downloadable file must fit into memory.
My PG knowledge isn't up to this task but I have a sneaking
suspicion this isn't really enforced by PG itself.
ODBC
> I tried this but was forced to store big files in 1 MB chunks in bytea
> fields and create file from downloaded blocks
Other client libraries may do better here.
> Or should I really write code which divides backup file to 1 MB chunks and
> stores them in bytea field ?
No. I would not even store them in the database at all. I
would use the untrusted language function to read the file
from disk and return a (virtual) bytea field (which doesn't
exist in the database).
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
