From: | Thomas Hallgren <thhal(at)mailblocks(dot)com> |
---|---|
To: | Markus Schaber <schabios(at)logi-track(dot)com> |
Cc: | "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>, Filip Hrbek <filip(dot)hrbek(at)plz(dot)comstar(dot)cz> |
Subject: | Re: PLJava and Database Meta Data |
Date: | 2005-02-11 12:07:47 |
Message-ID: | thhal-0lzjoAoNMxiceVLzfQR5Wq+0/NL/omO@mailblocks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Markus Schaber wrote:
>For complex datatypes, if you use the internal representation for your
>java mapping, you have to parse bytes, 32-bit integers, doubles and such
>from the in-memory representation.
>
We never parse any bytes. The internal representation of a double in the
backend is, a double. The SPI layer communicates values in terms of
datums that holds C-language char, short, int, long, float, double, etc.
values and JNI treats them as their native Java correspondance in the
Java layer. The same is true for the actuall call handler used for SQL
function calls into Java.
>Alternatively, you can use the canonical representations
>(using the types INPUT/OUTPUT/SEND/RECEIVE functions), but this incurs
>additional overhead.
>
>
Do you have any concrete measurments where this overhead is significant?
In my experience, using input/output/send/receive incurs a very low
overhead. I doubt that it's even measurable.
>Is there any documentation about such PLJava internals?
>
>
The source code :-)
Seriosly, if you want to know PLJava internals, it's not that bad to
look at. It's fairly well commented.
- thomas
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Schaber | 2005-02-11 12:54:50 | Re: PLJava and Database Meta Data |
Previous Message | Antony Paul | 2005-02-11 11:47:46 | Re: ERROR: column "total_cost" is of type numeric but expression |