From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | Maik Wiege <mswiege(at)gmx(dot)de> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: get row count from a "cursor resultset" |
Date: | 2005-07-06 22:50:50 |
Message-ID: | 42CC604A.9050604@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Oliver Jowett wrote:
> Oliver Jowett wrote:
>
>>Maik Wiege wrote:
>>
>>
>>>I didn't find a solution for this, but there must be, because the pgAdmin III - tool does this. After starting the query in the SQL-Dialog it asks wether to retrieve just the first 100 results or all results displaying the corect amount of found rows. Or is this just not possible with jdbc.
>>
>>
>>I'd point out that this does not require knowing exactly how many rows
>>there are -- only that there are more than 100. You can do the
>>equivalent in JDBC easily by setting fetchsize to 100 or so and calling
>>next() 100 times.. if you haven't hit the end of the resultset by that
>>point, it has more than 100 rows.
>
>
> Oh, sorry, my mistake -- I misread your description. Perhaps they are
> using either COUNT(*) in the same query or MOVE to get the number of rows.
Ok, some digging in pgAdmin's svn web interface seems to indicate that
pgadmin is not actually doing anything special here -- it does the full
query via libpq's PQexec(), retrieving all the tuples (and hence can
count them) but only does the work to construct a user interface
displaying them all after that "lots of rows, retrieve anyway?" dialog
has been answered.
You could check this by looking at pgadmin's memory footprint while
retrieving a big resultset.
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Maik Wiege | 2005-07-06 23:33:46 | Re: get row count from a "cursor resultset" |
Previous Message | Oliver Jowett | 2005-07-06 22:33:37 | Re: get row count from a "cursor resultset" |