Re: [RFC] How about changing the default value of defaultRowFetchSize?

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: Jorge Solórzano <jorsol(at)gmail(dot)com>, Vitalii Tymchyshyn <vit(at)tym(dot)im>, Mark Rotteveel <mark(at)lawinegevaar(dot)nl>, List <pgsql-jdbc(at)postgresql(dot)org>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
Subject: Re: [RFC] How about changing the default value of defaultRowFetchSize?
Date: 2016-10-24 11:12:31
Message-ID: CADK3HHJLoMUBZQ7DHtUD-KtRyqRSeyLSLpQnn2MKpzjHHtxWog@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

On 23 October 2016 at 23:12, Tsunakawa, Takayuki <
tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:

> From: pgsql-jdbc-owner(at)postgresql(dot)org
> > [mailto:pgsql-jdbc-owner(at)postgresql(dot)org] On Behalf Of Dave Cramer
> > ​defaultRowFetchSize is not an internal number.​ If you set the
> > property you get the value of the property.
> >
> >
> >
> >
> > That I agree with. If you don't set it you get 0
>
> You will get the value of defaultRowFetchSize if you don't call
> setFetchSize(), and the default value of defaultRowFetchSize will be, say,
> 100. As I mentioned in the previous mail, I think getFetchSize() returns
> the actual number of rows, not the hint (0).
>

This is what I take issue with. It should return 0 which means that it has
not been set. What use is it to the user ?

>
> Any comments on the default value of defaultRowFetchSize? There was a
> request for 1,000. I think 100 would be sufficient, considering the
> typical web pagination, for example. Those who want to speed up batch apps
> by reducing round trips can find the parameter and/or setFetchSize() and
> use them.
>

1000 has been determined to be optimal. Both Vladimir and I have done
performance testing on this. Also it won't matter to the user, since if
they only have 100 rows they will only get 100 rows back anyway. 1000 rows
should be able to fit into any reasonable client machines memory

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com

>
>

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message Robert Haas 2016-10-24 15:57:27 Re: Patch: Implement failover on libpq connect level.
Previous Message Victor Wagner 2016-10-24 11:09:57 Re: Patch: Implement failover on libpq connect level.