Re: [PERFORM] Large # of rows in query extremely slow, not using index

2004-09-23 Thread Stephen Crowley
Thanks for the explanation. So what sort of changes need to be made to the client/server protocol to fix this problem? On Thu, 23 Sep 2004 18:22:15 -0500 (EST), Kris Jurka <[EMAIL PROTECTED]> wrote: > > > On Tue, 14 Sep 2004, Stephen Crowley wrote: > > > Problem solved.. I set the fetchSize t

Re: [PERFORM] Large # of rows in query extremely slow, not using index

2004-09-13 Thread Stephen Crowley
Problem solved.. I set the fetchSize to a reasonable value instead of the default of unlimited in the PreparedStatement and now the query is . After some searching it seeems this is a common problem, would it make sense to change the default value to something other than 0 in the JDBC driver? If

Re: [PERFORM] Large # of rows in query extremely slow, not using index

2004-09-13 Thread Tom Lane
Stephen Crowley <[EMAIL PROTECTED]> writes: > On Mon, 13 Sep 2004 21:11:07 -0400, Tom Lane <[EMAIL PROTECTED]> wrote: >> Stephen Crowley <[EMAIL PROTECTED]> writes: >>> Does postgres cache the entire result set before it begins returning >>> data to the client? >> >> The backend doesn't, but libpq

Re: [PERFORM] Large # of rows in query extremely slow, not using index

2004-09-13 Thread Stephen Crowley
On Mon, 13 Sep 2004 21:11:07 -0400, Tom Lane <[EMAIL PROTECTED]> wrote: > Stephen Crowley <[EMAIL PROTECTED]> writes: > > Does postgres cache the entire result set before it begins returning > > data to the client? > > The backend doesn't, but libpq does, and I think JDBC does too. > > I'd recomm

Re: [PERFORM] Large # of rows in query extremely slow, not using index

2004-09-13 Thread Tom Lane
Stephen Crowley <[EMAIL PROTECTED]> writes: > Does postgres cache the entire result set before it begins returning > data to the client? The backend doesn't, but libpq does, and I think JDBC does too. I'd recommend using a cursor so you can FETCH a reasonable number of rows at a time. > Also, wh