Thread: JDBC slow performance on resultSet iteration?
Hello everyone, I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query. The query, although using PostGIS functions, is pretty straight forward: SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks,density FROM accidents_5 WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) ) ORDER BY _pk_id The results are the following: - Executing the query directly from pgAdmin: ~2807ms - Executing from JVM + JDBC: 4184ms The code i'm executing is pretty much standard: -------------------- code -------------------- public static void main(final String[] args) throws Exception { String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals,countdrunks, density"; sql += " FROM accidents_5"; sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603,4326) )"; sql += " ORDER BY _pk_id"; System.out.println(sql); Long time = System.currentTimeMillis(); try { Connection connection = DataStoreInfo.getDataStores().get(0); connection.setAutoCommit(false); System.out.println("[QUERY " + Thread.currentThread().getId() + "] - connection in " + (System.currentTimeMillis() - time) + "ms."); Statement st = connection.createStatement( ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, ResultSet.CLOSE_CURSORS_AT_COMMIT); st.setFetchSize(250); System.out.println("[QUERY " + Thread.currentThread().getId() + "] - statement in " + (System.currentTimeMillis() - time) + "ms."); ResultSet resultSet = st.executeQuery(sql); System.out.println("[QUERY " + Thread.currentThread().getId() + "] - done in " + (System.currentTimeMillis() - time) + "ms."); GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326); WKBReader wkbReader = new WKBReader(geofact); String id; String spatialType; Geometry geometry; String attribute; Long count; String reference; Map<String, Double> properties; String granularSynthString = "GranularSynthesis"; while (resultSet.next()) { id = resultSet.getString(1); spatialType = resultSet.getString(2); // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about thesame. attribute = resultSet.getString(4); count = resultSet.getLong(5); reference = resultSet.getString(6); properties = new HashMap<String, Double>(); Double aux = resultSet.getDouble(7); properties.put("countpersons", aux); aux = resultSet.getDouble(8); properties.put("countfatals", aux); aux = resultSet.getDouble(9); properties.put("countdrunks", aux); aux = resultSet.getDouble(10); properties.put("density", aux); } System.out.println("[QUERY " + Thread.currentThread().getId() + "] - done & iterated in " + (System.currentTimeMillis() - time) + "ms."); resultSet.close(); st.close(); connection.commit(); connection.close(); } catch (SQLException exception) { exception.printStackTrace(); // } catch (ParseException exception) { // ignored from WKBreader // exception.printStackTrace(); } System.out.println("[End " + Thread.currentThread().getId() + "] - done in " + (System.currentTimeMillis() - time) + "ms."); } -------------------- end code -------------------- Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also testedthis on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar. Is this expected? Can someone point if i'm doing something terrible wrong? I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC anditerating the resultSet are really annoying. Thanks in advance for any help. Kind regards, Rui Leal
Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver On 2013/11/05, at 16:09, Rui Pedro Leal wrote: > Hello everyone, > > I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query. > > The query, although using PostGIS functions, is pretty straight forward: > > SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks,density > FROM accidents_5 > WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) ) > ORDER BY _pk_id > > The results are the following: > - Executing the query directly from pgAdmin: ~2807ms > - Executing from JVM + JDBC: 4184ms > > The code i'm executing is pretty much standard: > > -------------------- code -------------------- > > public static void main(final String[] args) throws Exception { > > String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons,countfatals, countdrunks, density"; > sql += " FROM accidents_5"; > sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603,4326) )"; > sql += " ORDER BY _pk_id"; > > System.out.println(sql); > > Long time = System.currentTimeMillis(); > try { > Connection connection = DataStoreInfo.getDataStores().get(0); > connection.setAutoCommit(false); > > System.out.println("[QUERY " + Thread.currentThread().getId() > + "] - connection in " > + (System.currentTimeMillis() - time) + "ms."); > > Statement st = connection.createStatement( > ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY, > ResultSet.CLOSE_CURSORS_AT_COMMIT); > st.setFetchSize(250); > > System.out.println("[QUERY " + Thread.currentThread().getId() > + "] - statement in " + (System.currentTimeMillis() - time) > + "ms."); > > ResultSet resultSet = st.executeQuery(sql); > > System.out.println("[QUERY " + Thread.currentThread().getId() > + "] - done in " + (System.currentTimeMillis() - time) > + "ms."); > > GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326); > WKBReader wkbReader = new WKBReader(geofact); > > String id; > String spatialType; > Geometry geometry; > String attribute; > Long count; > String reference; > Map<String, Double> properties; > String granularSynthString = "GranularSynthesis"; > > while (resultSet.next()) { > id = resultSet.getString(1); > spatialType = resultSet.getString(2); > > // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are aboutthe same. > attribute = resultSet.getString(4); > count = resultSet.getLong(5); > reference = resultSet.getString(6); > > properties = new HashMap<String, Double>(); > Double aux = resultSet.getDouble(7); > properties.put("countpersons", aux); > aux = resultSet.getDouble(8); > properties.put("countfatals", aux); > aux = resultSet.getDouble(9); > properties.put("countdrunks", aux); > aux = resultSet.getDouble(10); > properties.put("density", aux); > } > > System.out.println("[QUERY " + Thread.currentThread().getId() > + "] - done & iterated in " > + (System.currentTimeMillis() - time) + "ms."); > > resultSet.close(); > st.close(); > connection.commit(); > connection.close(); > } catch (SQLException exception) { > exception.printStackTrace(); > // } catch (ParseException exception) { // ignored from WKBreader > // exception.printStackTrace(); > } > > System.out.println("[End " + Thread.currentThread().getId() > + "] - done in " + (System.currentTimeMillis() - time) + "ms."); > } > > -------------------- end code -------------------- > > Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also testedthis on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar. > > Is this expected? Can someone point if i'm doing something terrible wrong? > > I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBCand iterating the resultSet are really annoying. > > Thanks in advance for any help. > > Kind regards, > > Rui Leal > >
How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.
On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:
Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Hello Dave, thanks for the quick reply.
I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.
I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).
What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?
Regards,
Rui Leal
[] Rui Pedro Leal
On 2013/11/05, at 16:43, Dave Cramer wrote:
How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Rui Leal,
You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.
Just run a simple query and time it without iterating through the result set. That would be equivalent
On Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:
Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Dave,
That is not necessarily true. Most of the drivers data conversion is done in the getXXX calls of the ResultSet. All of which would count as “penalty”. I’m not saying it’s a large penalty, just that this is time that must be considered since pgAdmin is converting and displaying the data as well.
On Nov 5, 2013, at 10:34 AM, Dave Cramer <pg@fastcrypt.com> wrote:
Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Kevin,
Ya, however I am still questioning the basic time measurement.
On Tue, Nov 5, 2013 at 12:39 PM, Kevin Wooten <kdubb@me.com> wrote:
Dave,That is not necessarily true. Most of the drivers data conversion is done in the getXXX calls of the ResultSet. All of which would count as “penalty”. I’m not saying it’s a large penalty, just that this is time that must be considered since pgAdmin is converting and displaying the data as well.On Nov 5, 2013, at 10:34 AM, Dave Cramer <pg@fastcrypt.com> wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Em 05/11/2013 15:42, Dave Cramer escreveu:
Kevin,Ya, however I am still questioning the basic time measurement.On Tue, Nov 5, 2013 at 12:39 PM, Kevin Wooten <kdubb@me.com> wrote:Dave,That is not necessarily true. Most of the drivers data conversion is done in the getXXX calls of the ResultSet. All of which would count as “penalty”. I’m not saying it’s a large penalty, just that this is time that must be considered since pgAdmin is converting and displaying the data as well.On Nov 5, 2013, at 10:34 AM, Dave Cramer <pg@fastcrypt.com> wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Are you using a network between your station and the server?
You're connection using IP address or server name?
If the client machine has to access server several times (like in a cursor scenario), would be necessary to solve machine names, which could slow down the whole process.
Regards,
Edson
Dave,
I understand what you are saying, but i must get the results, right? :)
I think in pgAdmin the total query time, presented by the query execution windows, is also considering the rendering / presenting of the query results, so this is comparable ... right?
[] Rui Pedro Leal
On 2013/11/05, at 17:34, Dave Cramer wrote:
Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Kevin,
Exactly. I'm executing the query and presenting the results in pgAdmin. I assume pgAdmin is iterating through an equivalent of resultSet, getting each column, and presenting it in the results window.
On 2013/11/05, at 17:39, Kevin Wooten wrote:
Dave,That is not necessarily true. Most of the drivers data conversion is done in the getXXX calls of the ResultSet. All of which would count as “penalty”. I’m not saying it’s a large penalty, just that this is time that must be considered since pgAdmin is converting and displaying the data as well.On Nov 5, 2013, at 10:34 AM, Dave Cramer <pg@fastcrypt.com> wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
I do not know, the best way to figure this out is to use explain analyze in pg_admin.
What I am debating is the java code is using a cursor. pgAdmin is not.
Try it without setFetchSize()
On Tue, Nov 5, 2013 at 1:00 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:
Dave,I understand what you are saying, but i must get the results, right? :)I think in pgAdmin the total query time, presented by the query execution windows, is also considering the rendering / presenting of the query results, so this is comparable ... right?[] Rui Pedro LealOn 2013/11/05, at 17:34, Dave Cramer wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Hello Edson.
I'm running everything locally on a laptop. I simply connect to PG via JDBC localhost. Just a simple development setup.
[] Rui Pedro Leal
On 2013/11/05, at 17:47, Edson Richter wrote:
Are you using a network between your station and the server?
You're connection using IP address or server name?
If the client machine has to access server several times (like in a cursor scenario), would be necessary to solve machine names, which could slow down the whole process.
Regards,
Edson
Em 05/11/2013 15:42, Dave Cramer escreveu:
Kevin,Ya, however I am still questioning the basic time measurement.On Tue, Nov 5, 2013 at 12:39 PM, Kevin Wooten <kdubb@me.com> wrote:Dave,That is not necessarily true. Most of the drivers data conversion is done in the getXXX calls of the ResultSet. All of which would count as “penalty”. I’m not saying it’s a large penalty, just that this is time that must be considered since pgAdmin is converting and displaying the data as well.On Nov 5, 2013, at 10:34 AM, Dave Cramer <pg@fastcrypt.com> wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Rui,
The best way to settle this is to turn on log_duration in the server and get the server timings. That will give you the query time without rendering
On Tue, Nov 5, 2013 at 1:05 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:
Hello Edson.I'm running everything locally on a laptop. I simply connect to PG via JDBC localhost. Just a simple development setup.[] Rui Pedro LealOn 2013/11/05, at 17:47, Edson Richter wrote:Are you using a network between your station and the server?
You're connection using IP address or server name?
If the client machine has to access server several times (like in a cursor scenario), would be necessary to solve machine names, which could slow down the whole process.
Regards,
EdsonEm 05/11/2013 15:42, Dave Cramer escreveu:Kevin,Ya, however I am still questioning the basic time measurement.On Tue, Nov 5, 2013 at 12:39 PM, Kevin Wooten <kdubb@me.com> wrote:Dave,That is not necessarily true. Most of the drivers data conversion is done in the getXXX calls of the ResultSet. All of which would count as “penalty”. I’m not saying it’s a large penalty, just that this is time that must be considered since pgAdmin is converting and displaying the data as well.On Nov 5, 2013, at 10:34 AM, Dave Cramer <pg@fastcrypt.com> wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Dave,
Sure ... here it is ...
I've just replaced this:
--------------- code ---------------
Statement st = connection.createStatement(
ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
ResultSet.CLOSE_CURSORS_AT_COMMIT);
st.setFetchSize(250);
ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
ResultSet.CLOSE_CURSORS_AT_COMMIT);
st.setFetchSize(250);
ResultSet resultSet = st.executeQuery(sql);
------------- end code -------------
With this:
--------------- code ---------------
Statement st = connection.createStatement();
ResultSet resultSet = st.executeQuery(sql);
------------- end code -------------
------------- end code -------------
Result time is ~4760ms (vs. ~4184ms using the above fetchSize).
Thanks for the quick replies.
[] Rui Pedro Leal
On 2013/11/05, at 18:03, Dave Cramer wrote:
I do not know, the best way to figure this out is to use explain analyze in pg_admin.What I am debating is the java code is using a cursor. pgAdmin is not.Try it without setFetchSize()On Tue, Nov 5, 2013 at 1:00 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Dave,I understand what you are saying, but i must get the results, right? :)I think in pgAdmin the total query time, presented by the query execution windows, is also considering the rendering / presenting of the query results, so this is comparable ... right?[] Rui Pedro LealOn 2013/11/05, at 17:34, Dave Cramer wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Well I can speak from experience…
When I was comparing the performance of my implementation with pgjdbc I was very disheartened at the beginning as pgjdbc was seemingly much faster. It was only after I switched the test to take into account the getXXX calls that the true cost of using the driver was discovered. If you just execute a query and ignore the results pgjdbc is essentially just receiving a stream of text. It ignores all of the work of turning that text into Java objects/primitives.
My implementation uses binary protocol for this reason and that removes a lot of the overhead that pgjdbc has. If pgAdmin is using the binary protocol as well this could very well be the difference that is being seen, because it is a significant amount of time.
On Nov 5, 2013, at 11:03 AM, Dave Cramer <pg@fastcrypt.com> wrote:
I do not know, the best way to figure this out is to use explain analyze in pg_admin.What I am debating is the java code is using a cursor. pgAdmin is not.Try it without setFetchSize()On Tue, Nov 5, 2013 at 1:00 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Dave,I understand what you are saying, but i must get the results, right? :)I think in pgAdmin the total query time, presented by the query execution windows, is also considering the rendering / presenting of the query results, so this is comparable ... right?[] Rui Pedro LealOn 2013/11/05, at 17:34, Dave Cramer wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Em 05/11/2013 16:05, Rui Pedro Leal escreveu:
Hello Edson.Pedro,I'm running everything locally on a laptop. I simply connect to PG via JDBC localhost. Just a simple development setup.[] Rui Pedro LealOn 2013/11/05, at 17:47, Edson Richter wrote:Are you using a network between your station and the server?
You're connection using IP address or server name?
If the client machine has to access server several times (like in a cursor scenario), would be necessary to solve machine names, which could slow down the whole process.
Regards,
EdsonEm 05/11/2013 15:42, Dave Cramer escreveu:Kevin,Ya, however I am still questioning the basic time measurement.On Tue, Nov 5, 2013 at 12:39 PM, Kevin Wooten <kdubb@me.com> wrote:Dave,That is not necessarily true. Most of the drivers data conversion is done in the getXXX calls of the ResultSet. All of which would count as “penalty”. I’m not saying it’s a large penalty, just that this is time that must be considered since pgAdmin is converting and displaying the data as well.On Nov 5, 2013, at 10:34 AM, Dave Cramer <pg@fastcrypt.com> wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Would worth to change the "Long time = System.currentTimeMillis();" to just before the getResultSet(), otherwise other variables would be affecting results... like prepare time (and also initial connection).
Edson
And the server timings ? I suspect Kevin is correct here, it is in the conversion and display
On Tue, Nov 5, 2013 at 1:11 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:
Dave,Sure ... here it is ...I've just replaced this:--------------- code ---------------Statement st = connection.createStatement(
ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
ResultSet.CLOSE_CURSORS_AT_COMMIT);
st.setFetchSize(250);ResultSet resultSet = st.executeQuery(sql);------------- end code -------------With this:--------------- code ---------------Statement st = connection.createStatement();ResultSet resultSet = st.executeQuery(sql);
------------- end code -------------Result time is ~4760ms (vs. ~4184ms using the above fetchSize).Thanks for the quick replies.[] Rui Pedro LealOn 2013/11/05, at 18:03, Dave Cramer wrote:I do not know, the best way to figure this out is to use explain analyze in pg_admin.What I am debating is the java code is using a cursor. pgAdmin is not.Try it without setFetchSize()On Tue, Nov 5, 2013 at 1:00 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Dave,I understand what you are saying, but i must get the results, right? :)I think in pgAdmin the total query time, presented by the query execution windows, is also considering the rendering / presenting of the query results, so this is comparable ... right?[] Rui Pedro LealOn 2013/11/05, at 17:34, Dave Cramer wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Am I remembering incorrectly? I thought the driver only used binary for a few types and only if it was a prepared statement?
On Nov 5, 2013, at 11:18 AM, Dave Cramer <pg@fastcrypt.com> wrote:
I'd still like to know just how bad the getXXX calls are. Also the driver is using binary protocol, so it shouldn't be that badOn Tue, Nov 5, 2013 at 1:16 PM, Kevin Wooten <kdubb@me.com> wrote:Dave,I don’t believe he is not asking about the query time. He is specifically asking about the cost of using JDBC vs whatever pgAdmin is using (which seems to be libpq).On Nov 5, 2013, at 11:08 AM, Dave Cramer <pg@fastcrypt.com> wrote:Rui,The best way to settle this is to turn on log_duration in the server and get the server timings. That will give you the query time without renderingOn Tue, Nov 5, 2013 at 1:05 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Edson.I'm running everything locally on a laptop. I simply connect to PG via JDBC localhost. Just a simple development setup.[] Rui Pedro LealOn 2013/11/05, at 17:47, Edson Richter wrote:Are you using a network between your station and the server?
You're connection using IP address or server name?
If the client machine has to access server several times (like in a cursor scenario), would be necessary to solve machine names, which could slow down the whole process.
Regards,
EdsonEm 05/11/2013 15:42, Dave Cramer escreveu:Kevin,Ya, however I am still questioning the basic time measurement.On Tue, Nov 5, 2013 at 12:39 PM, Kevin Wooten <kdubb@me.com> wrote:Dave,That is not necessarily true. Most of the drivers data conversion is done in the getXXX calls of the ResultSet. All of which would count as “penalty”. I’m not saying it’s a large penalty, just that this is time that must be considered since pgAdmin is converting and displaying the data as well.On Nov 5, 2013, at 10:34 AM, Dave Cramer <pg@fastcrypt.com> wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
essentially everything is a prepared statement, and AFAIK, it is using binary protocol
On Tue, Nov 5, 2013 at 1:23 PM, Kevin Wooten <kdubb@me.com> wrote:
Am I remembering incorrectly? I thought the driver only used binary for a few types and only if it was a prepared statement?On Nov 5, 2013, at 11:18 AM, Dave Cramer <pg@fastcrypt.com> wrote:I'd still like to know just how bad the getXXX calls are. Also the driver is using binary protocol, so it shouldn't be that badOn Tue, Nov 5, 2013 at 1:16 PM, Kevin Wooten <kdubb@me.com> wrote:Dave,I don’t believe he is not asking about the query time. He is specifically asking about the cost of using JDBC vs whatever pgAdmin is using (which seems to be libpq).On Nov 5, 2013, at 11:08 AM, Dave Cramer <pg@fastcrypt.com> wrote:Rui,The best way to settle this is to turn on log_duration in the server and get the server timings. That will give you the query time without renderingOn Tue, Nov 5, 2013 at 1:05 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Edson.I'm running everything locally on a laptop. I simply connect to PG via JDBC localhost. Just a simple development setup.[] Rui Pedro LealOn 2013/11/05, at 17:47, Edson Richter wrote:Are you using a network between your station and the server?
You're connection using IP address or server name?
If the client machine has to access server several times (like in a cursor scenario), would be necessary to solve machine names, which could slow down the whole process.
Regards,
EdsonEm 05/11/2013 15:42, Dave Cramer escreveu:Kevin,Ya, however I am still questioning the basic time measurement.On Tue, Nov 5, 2013 at 12:39 PM, Kevin Wooten <kdubb@me.com> wrote:Dave,That is not necessarily true. Most of the drivers data conversion is done in the getXXX calls of the ResultSet. All of which would count as “penalty”. I’m not saying it’s a large penalty, just that this is time that must be considered since pgAdmin is converting and displaying the data as well.On Nov 5, 2013, at 10:34 AM, Dave Cramer <pg@fastcrypt.com> wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Hello Kevin,
That's exactly my immediate (and hopefully wrong) conclusion: the getXXX calls are really costly!
So, you are proposing using the binary protocol. I've never known the existence of that. Is this it: http://wiki.postgresql.org/wiki/JDBC-BinaryTransfer ?
Thanks.
[] Rui Pedro Leal
On 2013/11/05, at 18:14, Kevin Wooten wrote:
Well I can speak from experience…When I was comparing the performance of my implementation with pgjdbc I was very disheartened at the beginning as pgjdbc was seemingly much faster. It was only after I switched the test to take into account the getXXX calls that the true cost of using the driver was discovered. If you just execute a query and ignore the results pgjdbc is essentially just receiving a stream of text. It ignores all of the work of turning that text into Java objects/primitives.My implementation uses binary protocol for this reason and that removes a lot of the overhead that pgjdbc has. If pgAdmin is using the binary protocol as well this could very well be the difference that is being seen, because it is a significant amount of time.On Nov 5, 2013, at 11:03 AM, Dave Cramer <pg@fastcrypt.com> wrote:I do not know, the best way to figure this out is to use explain analyze in pg_admin.What I am debating is the java code is using a cursor. pgAdmin is not.Try it without setFetchSize()On Tue, Nov 5, 2013 at 1:00 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Dave,I understand what you are saying, but i must get the results, right? :)I think in pgAdmin the total query time, presented by the query execution windows, is also considering the rendering / presenting of the query results, so this is comparable ... right?[] Rui Pedro LealOn 2013/11/05, at 17:34, Dave Cramer wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
In the FE/BE protocol the Simple Query can only transfer in text. Doesn’t the driver use the simple query protocol in a lot of cases or is it always using the bind/exec version? Again, I may very well be misremembering how it works.
On Nov 5, 2013, at 11:25 AM, Dave Cramer <pg@fastcrypt.com> wrote:
essentially everything is a prepared statement, and AFAIK, it is using binary protocolOn Tue, Nov 5, 2013 at 1:23 PM, Kevin Wooten <kdubb@me.com> wrote:Am I remembering incorrectly? I thought the driver only used binary for a few types and only if it was a prepared statement?On Nov 5, 2013, at 11:18 AM, Dave Cramer <pg@fastcrypt.com> wrote:I'd still like to know just how bad the getXXX calls are. Also the driver is using binary protocol, so it shouldn't be that badOn Tue, Nov 5, 2013 at 1:16 PM, Kevin Wooten <kdubb@me.com> wrote:Dave,I don’t believe he is not asking about the query time. He is specifically asking about the cost of using JDBC vs whatever pgAdmin is using (which seems to be libpq).On Nov 5, 2013, at 11:08 AM, Dave Cramer <pg@fastcrypt.com> wrote:Rui,The best way to settle this is to turn on log_duration in the server and get the server timings. That will give you the query time without renderingOn Tue, Nov 5, 2013 at 1:05 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Edson.I'm running everything locally on a laptop. I simply connect to PG via JDBC localhost. Just a simple development setup.[] Rui Pedro LealOn 2013/11/05, at 17:47, Edson Richter wrote:Are you using a network between your station and the server?
You're connection using IP address or server name?
If the client machine has to access server several times (like in a cursor scenario), would be necessary to solve machine names, which could slow down the whole process.
Regards,
EdsonEm 05/11/2013 15:42, Dave Cramer escreveu:Kevin,Ya, however I am still questioning the basic time measurement.On Tue, Nov 5, 2013 at 12:39 PM, Kevin Wooten <kdubb@me.com> wrote:Dave,That is not necessarily true. Most of the drivers data conversion is done in the getXXX calls of the ResultSet. All of which would count as “penalty”. I’m not saying it’s a large penalty, just that this is time that must be considered since pgAdmin is converting and displaying the data as well.On Nov 5, 2013, at 10:34 AM, Dave Cramer <pg@fastcrypt.com> wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Hi Edson,
In fact i'm measuring on various steps as you can see by the code.
Where is a print of a simple execution .... this time with preparedStatement and fetchSize (250):
[QUERY 12] - connection in 7ms.
[QUERY 12] - statement in 7ms.
[QUERY 12] - done in 43ms.
[QUERY 12] - done & iterated in 4195ms.
And check the results just using a createStatement and no fetchSize/cursor:
[QUERY 12] - connection in 7ms.
[QUERY 12] - statement in 7ms.
[QUERY 12] - done in 3210ms.
[QUERY 12] - done & iterated in 4619ms.
The same query in pgAdmin is giving me the results (query + presenting / rendering) in 1601ms.
On 2013/11/05, at 18:14, Edson Richter wrote:
Pedro,
Would worth to change the "Long time = System.currentTimeMillis();" to just before the getResultSet(), otherwise other variables would be affecting results... like prepare time (and also initial connection).
Edson
Em 05/11/2013 16:05, Rui Pedro Leal escreveu:Hello Edson.I'm running everything locally on a laptop. I simply connect to PG via JDBC localhost. Just a simple development setup.[] Rui Pedro LealOn 2013/11/05, at 17:47, Edson Richter wrote:Are you using a network between your station and the server?
You're connection using IP address or server name?
If the client machine has to access server several times (like in a cursor scenario), would be necessary to solve machine names, which could slow down the whole process.
Regards,
EdsonEm 05/11/2013 15:42, Dave Cramer escreveu:Kevin,Ya, however I am still questioning the basic time measurement.On Tue, Nov 5, 2013 at 12:39 PM, Kevin Wooten <kdubb@me.com> wrote:Dave,That is not necessarily true. Most of the drivers data conversion is done in the getXXX calls of the ResultSet. All of which would count as “penalty”. I’m not saying it’s a large penalty, just that this is time that must be considered since pgAdmin is converting and displaying the data as well.On Nov 5, 2013, at 10:34 AM, Dave Cramer <pg@fastcrypt.com> wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Well yes and no. The driver may be transferring your data in binary already but we should work out if that is actually true. I believe that option "-Dorg.postgresql.forcebinary=boolean” still works and forces an Extended Query which will allow binary transfers.
Try running with that option and see if it changes the timings.
On Nov 5, 2013, at 11:27 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:
Hello Kevin,That's exactly my immediate (and hopefully wrong) conclusion: the getXXX calls are really costly!So, you are proposing using the binary protocol. I've never known the existence of that. Is this it: http://wiki.postgresql.org/wiki/JDBC-BinaryTransfer ?Thanks.[] Rui Pedro LealOn 2013/11/05, at 18:14, Kevin Wooten wrote:Well I can speak from experience…When I was comparing the performance of my implementation with pgjdbc I was very disheartened at the beginning as pgjdbc was seemingly much faster. It was only after I switched the test to take into account the getXXX calls that the true cost of using the driver was discovered. If you just execute a query and ignore the results pgjdbc is essentially just receiving a stream of text. It ignores all of the work of turning that text into Java objects/primitives.My implementation uses binary protocol for this reason and that removes a lot of the overhead that pgjdbc has. If pgAdmin is using the binary protocol as well this could very well be the difference that is being seen, because it is a significant amount of time.On Nov 5, 2013, at 11:03 AM, Dave Cramer <pg@fastcrypt.com> wrote:I do not know, the best way to figure this out is to use explain analyze in pg_admin.What I am debating is the java code is using a cursor. pgAdmin is not.Try it without setFetchSize()On Tue, Nov 5, 2013 at 1:00 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Dave,I understand what you are saying, but i must get the results, right? :)I think in pgAdmin the total query time, presented by the query execution windows, is also considering the rendering / presenting of the query results, so this is comparable ... right?[] Rui Pedro LealOn 2013/11/05, at 17:34, Dave Cramer wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Em 05/11/2013 16:45, Kevin Wooten escreveu:
Well yes and no. The driver may be transferring your data in binary already but we should work out if that is actually true. I believe that option "-Dorg.postgresql.forcebinary=boolean” still works and forces an Extended Query which will allow binary transfers.Does this patches already integrated into main stream driver source code?Try running with that option and see if it changes the timings.On Nov 5, 2013, at 11:27 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Kevin,That's exactly my immediate (and hopefully wrong) conclusion: the getXXX calls are really costly!So, you are proposing using the binary protocol. I've never known the existence of that. Is this it: http://wiki.postgresql.org/wiki/JDBC-BinaryTransfer ?Thanks.[] Rui Pedro LealOn 2013/11/05, at 18:14, Kevin Wooten wrote:Well I can speak from experience…When I was comparing the performance of my implementation with pgjdbc I was very disheartened at the beginning as pgjdbc was seemingly much faster. It was only after I switched the test to take into account the getXXX calls that the true cost of using the driver was discovered. If you just execute a query and ignore the results pgjdbc is essentially just receiving a stream of text. It ignores all of the work of turning that text into Java objects/primitives.My implementation uses binary protocol for this reason and that removes a lot of the overhead that pgjdbc has. If pgAdmin is using the binary protocol as well this could very well be the difference that is being seen, because it is a significant amount of time.On Nov 5, 2013, at 11:03 AM, Dave Cramer <pg@fastcrypt.com> wrote:I do not know, the best way to figure this out is to use explain analyze in pg_admin.What I am debating is the java code is using a cursor. pgAdmin is not.Try it without setFetchSize()On Tue, Nov 5, 2013 at 1:00 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Dave,I understand what you are saying, but i must get the results, right? :)I think in pgAdmin the total query time, presented by the query execution windows, is also considering the rendering / presenting of the query results, so this is comparable ... right?[] Rui Pedro LealOn 2013/11/05, at 17:34, Dave Cramer wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Edson
I believe it, or some version of it, is.
On Nov 5, 2013, at 11:50 AM, Edson Richter <edsonrichter@hotmail.com> wrote:
Em 05/11/2013 16:45, Kevin Wooten escreveu:Well yes and no. The driver may be transferring your data in binary already but we should work out if that is actually true. I believe that option "-Dorg.postgresql.forcebinary=boolean” still works and forces an Extended Query which will allow binary transfers.Does this patches already integrated into main stream driver source code?Try running with that option and see if it changes the timings.On Nov 5, 2013, at 11:27 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Kevin,That's exactly my immediate (and hopefully wrong) conclusion: the getXXX calls are really costly!So, you are proposing using the binary protocol. I've never known the existence of that. Is this it: http://wiki.postgresql.org/wiki/JDBC-BinaryTransfer ?Thanks.[] Rui Pedro LealOn 2013/11/05, at 18:14, Kevin Wooten wrote:Well I can speak from experience…When I was comparing the performance of my implementation with pgjdbc I was very disheartened at the beginning as pgjdbc was seemingly much faster. It was only after I switched the test to take into account the getXXX calls that the true cost of using the driver was discovered. If you just execute a query and ignore the results pgjdbc is essentially just receiving a stream of text. It ignores all of the work of turning that text into Java objects/primitives.My implementation uses binary protocol for this reason and that removes a lot of the overhead that pgjdbc has. If pgAdmin is using the binary protocol as well this could very well be the difference that is being seen, because it is a significant amount of time.On Nov 5, 2013, at 11:03 AM, Dave Cramer <pg@fastcrypt.com> wrote:I do not know, the best way to figure this out is to use explain analyze in pg_admin.What I am debating is the java code is using a cursor. pgAdmin is not.Try it without setFetchSize()On Tue, Nov 5, 2013 at 1:00 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Dave,I understand what you are saying, but i must get the results, right? :)I think in pgAdmin the total query time, presented by the query execution windows, is also considering the rendering / presenting of the query results, so this is comparable ... right?[] Rui Pedro LealOn 2013/11/05, at 17:34, Dave Cramer wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Edson
On 11/05/2013 12:55 PM, Kevin Wooten wrote: > I believe it, or some version of it, is. Interesting thread, but good god! would you guys trim your posts? -- Glenn Holmer Weyco Group, Inc. phone: 414-908-1809 fax: 414-908-1601
Em 05/11/2013 17:31, Glenn Holmer escreveu: > On 11/05/2013 12:55 PM, Kevin Wooten wrote: >> I believe it, or some version of it, is. > > Interesting thread, but good god! would you guys trim your posts? > I used to answer as in PostgreSQL list... "do not top post, keep the thread" :-)
Hi Kevin,
I've tested that "-Dorg.postgresql.forcebinary=true” options with no apparent benefits.
Just recapping ...
Using postgres 9.1.2 + postgis .... with the 9.2-1003-jdbc4 driver.
For the sake of having consistent result, I'm now just focused now on running a createStatement / executeQuery with no cursor or fetchSize stuff (as per Dave suggestion).
As i've presented in my previous code, i'm measuring the process from the beginning to the end (always accumulating time) and measuring connection creation, statement creation (i was using preparedStatement previously), query execution and result set iteration + resultSet.getXXX.
So currently, i'm getting the following results (last execution after arriving at home):
[QUERY 12] - connection in 8ms.
[QUERY 12] - statement in 8ms.
[QUERY 12] - done/execution in 3035ms.
[QUERY 12] - iterated in 4381ms.
Comparing to pgAdmin, where executing the query and presenting all the results is around ~2663ms (last execution after arriving at home).
So, my conclusions so far ... to which i welcome feedback or pointing out my utterly stupidity ;)
1) The performance difference on the execution is for me quite expected, not that abnormal and almost negligible (from my previous experience with JDBC on Oracle and MySQL).
2) However, the step of the iteration/gets on the resultSet (190k) .... which is mostly all resultSet.getXXX (please check my original code / post) is an additional 1.3s. If the query results are in fact in memory, it is strange and puzzling to me.
In the end, i'm getting an additional 1.7s performance hit vs. a simple query and return results of pgAdmin.
Tomorrow i will follow Dave Cramer suggestion and turn on log_duration on the server and check in more detail the server logs. Will report back.
Any additional feedback or suggestion?
Thanks everyone for the promptly feedback ...
Regards,
Rui Leal
[] Rui Pedro Leal
On 2013/11/05, at 18:45, Kevin Wooten wrote:
Well yes and no. The driver may be transferring your data in binary already but we should work out if that is actually true. I believe that option "-Dorg.postgresql.forcebinary=boolean” still works and forces an Extended Query which will allow binary transfers.Try running with that option and see if it changes the timings.On Nov 5, 2013, at 11:27 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Kevin,That's exactly my immediate (and hopefully wrong) conclusion: the getXXX calls are really costly!So, you are proposing using the binary protocol. I've never known the existence of that. Is this it: http://wiki.postgresql.org/wiki/JDBC-BinaryTransfer ?Thanks.[] Rui Pedro LealOn 2013/11/05, at 18:14, Kevin Wooten wrote:Well I can speak from experience…When I was comparing the performance of my implementation with pgjdbc I was very disheartened at the beginning as pgjdbc was seemingly much faster. It was only after I switched the test to take into account the getXXX calls that the true cost of using the driver was discovered. If you just execute a query and ignore the results pgjdbc is essentially just receiving a stream of text. It ignores all of the work of turning that text into Java objects/primitives.My implementation uses binary protocol for this reason and that removes a lot of the overhead that pgjdbc has. If pgAdmin is using the binary protocol as well this could very well be the difference that is being seen, because it is a significant amount of time.On Nov 5, 2013, at 11:03 AM, Dave Cramer <pg@fastcrypt.com> wrote:I do not know, the best way to figure this out is to use explain analyze in pg_admin.What I am debating is the java code is using a cursor. pgAdmin is not.Try it without setFetchSize()On Tue, Nov 5, 2013 at 1:00 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Dave,I understand what you are saying, but i must get the results, right? :)I think in pgAdmin the total query time, presented by the query execution windows, is also considering the rendering / presenting of the query results, so this is comparable ... right?[] Rui Pedro LealOn 2013/11/05, at 17:34, Dave Cramer wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
Hi, Rui,
I'm very interested in knowing your results.
Please, share your advances with us...
Regards,
Edson
Em 06/11/2013 01:46, Rui Pedro Leal escreveu:
I'm very interested in knowing your results.
Please, share your advances with us...
Regards,
Edson
Em 06/11/2013 01:46, Rui Pedro Leal escreveu:
Hi Kevin,I've tested that "-Dorg.postgresql.forcebinary=true” options with no apparent benefits.Just recapping ...Using postgres 9.1.2 + postgis .... with the 9.2-1003-jdbc4 driver.For the sake of having consistent result, I'm now just focused now on running a createStatement / executeQuery with no cursor or fetchSize stuff (as per Dave suggestion).As i've presented in my previous code, i'm measuring the process from the beginning to the end (always accumulating time) and measuring connection creation, statement creation (i was using preparedStatement previously), query execution and result set iteration + resultSet.getXXX.So currently, i'm getting the following results (last execution after arriving at home):[QUERY 12] - connection in 8ms.[QUERY 12] - statement in 8ms.[QUERY 12] - done/execution in 3035ms.[QUERY 12] - iterated in 4381ms.If i recall correctly, since i'm not using fetchSize all results should be loaded to memory, if there is space (around 190k of them).Comparing to pgAdmin, where executing the query and presenting all the results is around ~2663ms (last execution after arriving at home).So, my conclusions so far ... to which i welcome feedback or pointing out my utterly stupidity ;)1) The performance difference on the execution is for me quite expected, not that abnormal and almost negligible (from my previous experience with JDBC on Oracle and MySQL).2) However, the step of the iteration/gets on the resultSet (190k) .... which is mostly all resultSet.getXXX (please check my original code / post) is an additional 1.3s. If the query results are in fact in memory, it is strange and puzzling to me.In the end, i'm getting an additional 1.7s performance hit vs. a simple query and return results of pgAdmin.Tomorrow i will follow Dave Cramer suggestion and turn on log_duration on the server and check in more detail the server logs. Will report back.Any additional feedback or suggestion?Thanks everyone for the promptly feedback ...Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 18:45, Kevin Wooten wrote:Well yes and no. The driver may be transferring your data in binary already but we should work out if that is actually true. I believe that option "-Dorg.postgresql.forcebinary=boolean” still works and forces an Extended Query which will allow binary transfers.Try running with that option and see if it changes the timings.On Nov 5, 2013, at 11:27 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Kevin,That's exactly my immediate (and hopefully wrong) conclusion: the getXXX calls are really costly!So, you are proposing using the binary protocol. I've never known the existence of that. Is this it: http://wiki.postgresql.org/wiki/JDBC-BinaryTransfer ?Thanks.[] Rui Pedro LealOn 2013/11/05, at 18:14, Kevin Wooten wrote:Well I can speak from experience…When I was comparing the performance of my implementation with pgjdbc I was very disheartened at the beginning as pgjdbc was seemingly much faster. It was only after I switched the test to take into account the getXXX calls that the true cost of using the driver was discovered. If you just execute a query and ignore the results pgjdbc is essentially just receiving a stream of text. It ignores all of the work of turning that text into Java objects/primitives.My implementation uses binary protocol for this reason and that removes a lot of the overhead that pgjdbc has. If pgAdmin is using the binary protocol as well this could very well be the difference that is being seen, because it is a significant amount of time.On Nov 5, 2013, at 11:03 AM, Dave Cramer <pg@fastcrypt.com> wrote:I do not know, the best way to figure this out is to use explain analyze in pg_admin.What I am debating is the java code is using a cursor. pgAdmin is not.Try it without setFetchSize()On Tue, Nov 5, 2013 at 1:00 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Dave,I understand what you are saying, but i must get the results, right? :)I think in pgAdmin the total query time, presented by the query execution windows, is also considering the rendering / presenting of the query results, so this is comparable ... right?[] Rui Pedro LealOn 2013/11/05, at 17:34, Dave Cramer wrote:Rui Leal,You shouldn't see that much of a penatly, but I question how you are measuring it. Since you are timing the loop which is using cursors.Just run a simple query and time it without iterating through the result set. That would be equivalentOn Tue, Nov 5, 2013 at 12:16 PM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Hello Dave, thanks for the quick reply.I'm just executing the same query on pgAdmin query interface. Just a way to measure performance of the query + getting results vs the JDBC way.I'm using fetchsize in order to get some faster results when iterating the resultSet. I've tried not to use fetchSize/cursor but the performance is naturally slower (and worser than the simple pgAdmin query).What i'm asking is .. is this performance penalty i'm getting using postgres JDBC normal and within what's expected? I'm i doing something wrong? Can i do it in any other way?Regards,Rui Leal[] Rui Pedro LealOn 2013/11/05, at 16:43, Dave Cramer wrote:How can you measure the same query in pgAdmin ? JDBC will use a cursor when you set the fetchsize.On Tue, Nov 5, 2013 at 11:12 AM, Rui Pedro Leal <rui.pedro.leal@gmail.com> wrote:Just an quick info update: i'm using the postgresql-9.2-1003-jdbc4 driver
On 2013/11/05, at 16:09, Rui Pedro Leal wrote:
> Hello everyone,
>
> I'm having slow JDBC performance on iterating a resultSet obtained from a somewhat simple query.
>
> The query, although using PostGIS functions, is pretty straight forward:
>
> SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density
> FROM accidents_5
> WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )
> ORDER BY _pk_id
>
> The results are the following:
> - Executing the query directly from pgAdmin: ~2807ms
> - Executing from JVM + JDBC: 4184ms
>
> The code i'm executing is pretty much standard:
>
> -------------------- code --------------------
>
> public static void main(final String[] args) throws Exception {
>
> String sql = "SELECT _id, _spatial_type, ST_AsBinary(_geometry), _attribute, _count, _references, countpersons, countfatals, countdrunks, density";
> sql += " FROM accidents_5";
> sql += " WHERE (_geometry && ST_MakeEnvelope(-126.60644531250001,26.43122806450644,-63.369140625,52.96187505907603, 4326) )";
> sql += " ORDER BY _pk_id";
>
> System.out.println(sql);
>
> Long time = System.currentTimeMillis();
> try {
> Connection connection = DataStoreInfo.getDataStores().get(0);
> connection.setAutoCommit(false);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - connection in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> Statement st = connection.createStatement(
> ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY,
> ResultSet.CLOSE_CURSORS_AT_COMMIT);
> st.setFetchSize(250);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - statement in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> ResultSet resultSet = st.executeQuery(sql);
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time)
> + "ms.");
>
> GeometryFactory geofact = new GeometryFactory(new PrecisionModel(),4326);
> WKBReader wkbReader = new WKBReader(geofact);
>
> String id;
> String spatialType;
> Geometry geometry;
> String attribute;
> Long count;
> String reference;
> Map<String, Double> properties;
> String granularSynthString = "GranularSynthesis";
>
> while (resultSet.next()) {
> id = resultSet.getString(1);
> spatialType = resultSet.getString(2);
>
> // geometry = wkbReader.read(resultSet.getBytes(3)); // ignored the WKBReader and the results are about the same.
> attribute = resultSet.getString(4);
> count = resultSet.getLong(5);
> reference = resultSet.getString(6);
>
> properties = new HashMap<String, Double>();
> Double aux = resultSet.getDouble(7);
> properties.put("countpersons", aux);
> aux = resultSet.getDouble(8);
> properties.put("countfatals", aux);
> aux = resultSet.getDouble(9);
> properties.put("countdrunks", aux);
> aux = resultSet.getDouble(10);
> properties.put("density", aux);
> }
>
> System.out.println("[QUERY " + Thread.currentThread().getId()
> + "] - done & iterated in "
> + (System.currentTimeMillis() - time) + "ms.");
>
> resultSet.close();
> st.close();
> connection.commit();
> connection.close();
> } catch (SQLException exception) {
> exception.printStackTrace();
> // } catch (ParseException exception) { // ignored from WKBreader
> // exception.printStackTrace();
> }
>
> System.out.println("[End " + Thread.currentThread().getId()
> + "] - done in " + (System.currentTimeMillis() - time) + "ms.");
> }
>
> -------------------- end code --------------------
>
> Although i'm executing this on slow MacbookPro (2.6 core duo, 2Gbs RAM but SSD) and have a 9.1.2 postgres, i've also tested this on a recent retina MBP and the ratio between pgAdmin and JDBC execution is similar.
>
> Is this expected? Can someone point if i'm doing something terrible wrong?
>
> I'm not concerned about the query performance per-se (i know it CAN be optimized), but the differences just using JDBC and iterating the resultSet are really annoying.
>
> Thanks in advance for any help.
>
> Kind regards,
>
> Rui Leal
>
>
--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc