Re: 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.

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