Re: [JDBC] TypeInfoCache

Hello Oliver,

I redid the benchmark, now with 10,000,000 iterations and externalized functions. Thank you for your hints on writing good benchmarks. These are the results:

    getString on text_col took 9015.563444ms     getCharacterStream on text_col took 12239.496833ms     Factor: 1.3575964396485478

    getString on varchar_col took 9047.101624ms     getCharacterStream on varchar_col took 12268.299423ms     Factor: 1.3560474871261377

A feel a bit ashamed of the different results, now, but nontheless do they still speak what I wanted to say: We have a 35% percent slowdown JUST on the getStream-Method, regardless of a varchar or a text type. This is not much if seen in a real life application where the actual waiting for the data is the real bottleneck.

And this is just a small slowdown, if the applicatin does not use getString() on the LONGVARCHAR anyway!

So I don't see any problems here.

I can understand your concerns, if you are used to applications that store everything in text-fields on the database. But a problem is only if you have such an applicatoin, and forgets about its database fields and uses the metadata to remember what its fields have been, now notices the data is in LONGVARCHARs, and uses the stream-methods. But normally, if you create such a database, you created it just for postgresql anyway, want to stay with postgresql, and have access to the code that accesses the JDBC driver. But this again will only contain getString()-Methods, as it was used to, and so your code does not have any penalty if we apply the patch.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related postgresql.org Links pgsql-admin pgsql-advocacy pgsql-announce pgsql-bugs pgsql-cygwin pgsql-docs pgsql-general pgsql-interfaces pgsql-jdbc pgsql-jobs pgsql-novice pgsql-odbc pgsql-performance pgsql-php pgsql-ports pgsql-sql Request more information about Pantek

Please think about this again. Only the very generic applications need the metadata. And if the fields might contain very large data, it is good if they use the "slow" interface. The 33% will be reduced to max 1% at all anyways if mixed in the other code.

Thank you and with best regards,
Daniel Migowski

Oliver Jowett schrieb:
> Daniel Migowski wrote:
>
>> getString on text_col took 8.27384ms
>> getCharacterStream on text_col took 14.26489ms
>> Factor: 1.724095462324628
>> getString on varchar_col took 9.57153ms
>> getCharacterStream on varchar_col took 12.76733ms
>> Factor: 1.3338860140437319
>
>> Conclusion: There is no real performance loss even in the worst case
>> (which should never occur anyway), so please accept my patch. I wish
>> you all a happy new year!
>
> I'm confused. Don't your numbers show a 30%-70% slowdown when using
> getCharacterStream()?
>
> Also some quick notes about microbenchmarks:
>
> - 1000 iterations isn't really enough to get useful numbers, try
> 20,000+ for JIT effects or considerably more for GC effects
> - server vs. client JVM can have quite different behaviours, you
> should check both
> - put your inner benchmark loops in a separate method as some JIT has
> method-level granularity
> - benchmark the same code path in your warmup loop as you actually
> measure the numbers from. In your code, you're benchmarking a
> different code path to the one you run in your warmup loop.
>
> -O
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster

---------------------------(end of broadcast)---------------------------

               http://www.postgresql.org/docs/faq Received on Mon Jan 7 14:19:06 2008