From: | "Nicholas E(dot) Wakefield" <nwakefield(at)KineticNetworks(dot)com> |
---|---|
To: | <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: how to monitor the amount of bytes fetched in a executeQuery() |
Date: | 2006-07-12 03:17:56 |
Message-ID: | 2F2A7EB72EBAF24582513E72ACCBCAAE11A2D6@kniexch01.KineticNetworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
You could possibly modify the driver to start a thread in the background
to monitor the progress - hack. I just did some very similar to monitor
the amount of memory being used by a result set as it was being
generated.
-----Original Message-----
From: pgsql-jdbc-owner(at)postgresql(dot)org
[mailto:pgsql-jdbc-owner(at)postgresql(dot)org] On Behalf Of Oliver Jowett
Sent: Tuesday, July 11, 2006 10:11 PM
To: Albert Cardona
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: [JDBC] how to monitor the amount of bytes fetched in a
executeQuery()
Albert Cardona wrote:
> I have a system in which large (13Mb) images are stored in the
database as
> compressed bytea column entries. When fetching from the local computer
it's
> fast enough the lag is not noticeable. When fetching remotely at 1Mb
LAN
> speed, about 15 seconds elapse.
>
> After timing the executeQuery() and the getBinaryStream(), the first
takes
> about 15 seconds and the second about 3. So it looks like the
executeQuery()
> is actually downloading the image, and the getBinaryStream is merely
copying
> it from a local resource. Is that right?
Yes.
> Is there any way in which the number of bytes fetched in a query or
for a
> particular column can be monitored, so I can display a more accurate
and
> elaborated waiting dialog in my application?
I can't see any way to do this, unfortunately.
-O
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
From | Date | Subject | |
---|---|---|---|
Next Message | Oliver Jowett | 2006-07-12 05:01:47 | Re: Limit vs setMaxRows issue |
Previous Message | Chris White (cjwhite) | 2006-07-11 18:55:18 | unsubscribe |