Re: PLJava and Database Meta Data

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

In response to

Responses

Browse pgsql-jdbc by date

  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