Thursday, 2010-07-08

*** grantc has joined #ingres00:13
*** grantc has quit IRC00:13
*** grantc has joined #ingres00:14
*** KermitTheFragger has joined #ingres00:34
*** atrofast has joined #ingres02:32
*** atrofast has quit IRC02:37
*** atrofast has joined #ingres02:38
*** grantc has quit IRC02:58
*** grantc has joined #ingres03:14
pboroatrofast, geotools stuff progressing well? :)03:41
atrofastpboro: pretty well, there seems to be a bug in MVCC and LOB handling that needs resolving03:48
pboronice to hear03:50
atrofastYeah... oh how familiar are you with JDBC and LOBs anyway pboro? Can you actually insert a LONG VARCHAR longer than 32000 bytes NOT using PreparedStatements?04:00
pboroas far as I know, you can't04:00
atrofastSo you gotta use PreparedStatements for LOBs the neh?04:01
pboroyup04:01
pboroI usually only use prepared statements for the security they provided by using placeholders04:02
atrofastGood to know... I wrote a second driver for GeoTools (utilizing much of the first one) last night but to use Prepared Statements instead... was pretty sure something like that would come up :)04:02
atrofastHow does performance compare?04:02
atrofastprepared vs not prepared04:02
pborowell the server needs to "prepare" the statement any way, you just get a possibility to reuse the once already prepared statement...if you're using statement pooling, the jdbc pooling library can keep the statements in a "pooled cache"04:03
pboroso you should get benefits in that case, since the statement only needs to be prepared once for each connection04:04
pboropooling libraries like c3p0 and apache dbcp support also pooling the statements, which is nice04:05
pborobut of course there's a small penalty in using preparedstatement since the statement will be "stored" for a while etc., but if you really need performance you will need to use prepared statement to make them cacheable/poolable04:05
pboroI might be wrong, but this is how I understand and do it :)04:06
pboroof course you can also reuse the statements in your code, without a caching/pooling library between your application and jdbc driver04:07
atrofastThat makes sense... I'm not sure what kind of strategy GeoTools uses if it's pooling... But I guess it's a moot point since I need to prepare my statements in case the geometries are large04:09
pboromostly the pooling library is put between the application and the jdbc driver and the software doesn't take any part in it04:10
pborothe library just works as a caching layer04:10
pboroyou can use it or leave it out, either way you like04:10
pboroin some cases it's a must, like some high volume web applications04:11
pboroall java web application frameworks only use prepared statements, like Spring Framework04:11
pboroso... I would really go with the prepared ones :)04:11
atrofastThanks for the input, very useful :) Yeah looking over the other drivers, Oracle has ONLY a PreparedStatement driver. Postgres has both... MySQL and SQLServer has no Prepared Statement driver04:15
pboroprepared statements is something that MySQL lacked a long time even for PHP04:15
pboroMySQL 5.1+ does support prepared statements in it's JDBC driver04:16
pboromaybe older too, can't find good source on the versions right now...04:17
pborosupport for prepared statements on the server side was added in 4.104:17
pborohehe, some statistics: http://euedge.com/blog/2007/11/11/prepared-statement-performance-in-mysql/04:18
pboronot too good test tho'04:19
*** javahorn has joined #ingres04:47
*** javahorn has left #ingres04:47
atrofastAre there any Ingres benchmarks similar to that?05:07
pboronope... if I had some spare time, I would be glad to make one05:08
*** cthibert has joined #ingres05:10
atrofastjust something that would be interesting at this point, not resting any key decisions on it or anything :)05:11
pboroit would be interesting to see the effect of cache_dynamic = ON too05:11
atrofastyes agreed05:15
*** rossand has joined #ingres05:30
*** ChanServ sets mode: +o rossand05:30
*** Dejan has joined #ingres06:03
*** Mud has joined #ingres06:07
Dejanhello guys06:08
*** mull has quit IRC06:11
*** Alex| has quit IRC06:18
*** Alex| has joined #ingres06:38
*** ChanServ sets mode: +o Alex|06:38
*** mull has joined #ingres06:42
*** toumi01 has joined #ingres06:48
*** cthibert has left #ingres07:35
*** cthibert has joined #ingres07:37
*** Alex| has quit IRC07:57
*** toumi01 has quit IRC08:16
*** MikeT has joined #ingres08:23
*** MikeT is now known as Guest3780108:24
*** Guest37801 has left #ingres08:24
*** toumi01 has joined #ingres08:25
*** Dejan has quit IRC09:28
*** Alex| has joined #ingres09:36
*** ChanServ sets mode: +o Alex|09:36
*** grantc has quit IRC10:49
*** KermitTheFragger has quit IRC10:54
*** thiagomz has joined #ingres10:57
thiagomzGuys... I am trying to migrate a 2.6 legacy database to 10.0 Community edition.... I got a lot of this : E_CO003F COPY: Warning: 51543 rows not copied because duplicate key10:58
thiagomz    detected10:58
thiagomzAnyone has i ideia why ?10:58
*** rossand has quit IRC11:00
*** rossand has joined #ingres11:02
*** ChanServ sets mode: +o rossand11:02
*** Alex| has quit IRC11:41
*** toumi01 has left #ingres11:57
*** toumi01 has joined #ingres11:58
*** toumi01 has quit IRC12:06
*** toumi01 has joined #ingres12:06
*** toumi01 has quit IRC12:10
*** toumi01 has joined #ingres12:10
*** thiagomz has left #ingres13:46
*** cthibert has left #ingres14:15
*** mull has quit IRC14:27
*** atrofast has quit IRC14:55
*** Mud has quit IRC14:58
*** toumi01 has quit IRC15:55
*** mull has joined #ingres16:31
*** cytrinox_ has joined #ingres19:21
*** cytrinox has quit IRC19:21
*** cytrinox_ is now known as cytrinox19:21
*** rossand has quit IRC19:40
*** mull has quit IRC19:52
*** Alex| has joined #ingres22:37
*** ChanServ sets mode: +o Alex|22:37
*** Mud has joined #ingres22:42
*** Alex| has quit IRC23:26
*** Alex| has joined #ingres23:39
*** ChanServ sets mode: +o Alex|23:39

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!