SEO

Hi, Thomas,

Thomas Hallgren schrieb:
> PLJava has its own JDBC driver that is implemented directly on top of
> JDBC.

Did you do anything concerning custom datatypes (e. G. PostGIS) yet?

The pgjdbc PGobject interface will need some overhaul (or a complete
rework) to make use of the binary representation with V3 protocol
support, maybe that you (PLJava), the pgjdbc pepole, we (PostGIS) and
others could join to create a common interface, enabling users to use
the same extension jar for both client and server side.

Markus
--
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios@logi-track.com | www.logi-track.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCDIR4OVWsnapT9i0RAir5AJ9Gh8Iw4QTAte+UB8/d8/1vzQcDRQCgjAfR
sfc2TvqEYZYyD9MifrEvjmg=
=4S7f
-----END PGP SIGNATURE-----

Markus,

>Did you do anything concerning custom datatypes (e. G. PostGIS) yet?
>
>The pgjdbc PGobject interface will need some overhaul (or a complete
>rework) to make use of the binary representation with V3 protocol
>support, maybe that you (PLJava), the pgjdbc pepole, we (PostGIS) and
>others could join to create a common interface, enabling users to use
>the same extension jar for both client and server side.
>
>
Nothing has been done in this area for PLJava yet. I'm definitely in
favor of your suggestion. If anything can be done to converge efforts
and API's, it should be done.

Regards,
Thomas Hallgren



---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Hi, Thomas,

Thomas Hallgren schrieb:

>> Did you do anything concerning custom datatypes (e. G. PostGIS) yet?
>>[...]
>
> Nothing has been done in this area for PLJava yet. I'm definitely in
> favor of your suggestion. If anything can be done to converge efforts
> and API's, it should be done.

Okay. Maybe we should also invite other custom datatype authors.

Just out of curiosity (I did not have enough time to take a close look
at PLJava yet - maybe I should do that first...): How do you currently
model types like Interval, Money, ByteArray or the native PostgreSQL
geometry types? (I ask this because in pgjdbc they are currently
implemented using the same PGobject approach as PostGIS extension types.)

And what is your approach to endianness conversion?

Markus
--
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios@logi-track.com | www.logi-track.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCDI8WOVWsnapT9i0RAh19AKDooqM5Nhz+Ld8+7AB0HP qKkfDTfgCgv8V6
Ifl5SyiKK4G/Mx3kfzUQmLQ=
=v/v7
-----END PGP SIGNATURE-----

Hi, Thomas,

Thomas Hallgren schrieb:

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

Okay, so this is fine for primitive types. How does SPI deal with
complex types?

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

Yes, I have. Especially for large geometries. In our database, we have
geometry objects up to 20MB per piece. Also, in PostGIS, send/receive
binary representation differs slightly from internal representation (and
input/output text is even more overhead).

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

Okay, I'll do so.

Markus

--
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios@logi-track.com | www.logi-track.com

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Markus Schaber wrote:

>Okay, so this is fine for primitive types. How does SPI deal with
>complex types?
>
>
A complex type is represented by a C-structure called HeapTuple. A
HeapTuple is associated with a TupleDesc that acts as its description.
The HeapTuple is passed by reference (a C-language pointer) and PLJava
will obtains its individual values as Datums using a function called
SPI_getbinval. An individual value may of course be a reference to
another complex type.

Complex types are created using the function heap_form_tuple.

>Yes, I have. Especially for large geometries. In our database, we have
>geometry objects up to 20MB per piece. Also, in PostGIS, send/receive
>binary representation differs slightly from internal representation (and
>input/output text is even more overhead).
>
>
Ok. We are probably talking about different things. I'm referring to the
internal C-functions that are executed directly in the backend.

- thomas



---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Laszlo Hornyak wrote:

>Thomas,
>
>FYI, PL-J typemapper framework.
>http://cvs.plj.codehaus.org/*checkou...r.java?rev=1.4
>
>Regards,
>Laszlo
>
>
Yepp. I have the pl-j CVS in my workspace :-)

- thomas



---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

Hi, Thomas,

Thomas Hallgren schrieb:

>> Okay, so this is fine for primitive types. How does SPI deal with
>> complex types?
>>
> A complex type is represented by a C-structure called HeapTuple. A
> HeapTuple is associated with a TupleDesc that acts as its description.
> The HeapTuple is passed by reference (a C-language pointer) and PLJava
> will obtains its individual values as Datums using a function called
> SPI_getbinval. An individual value may of course be a reference to
> another complex type.
>
> Complex types are created using the function heap_form_tuple.

Okay, sounds good. So it seems that PostGIS/PLJava would need some
understanding of PostGIS internal layout in addition to the canonical
representations it uses on the client side.

Two additional features that are needed to parse the PostGIS internal
rep are optional fields (presence is flagged by bits in other fields)
and arrays (both as complex types). And there must be no issues with
strange alignments.

(All of this how I remember the discussions on the PostGIS mailing list,
I did not do any server-side PostGIS coding myself up to now.)

>> Yes, I have. Especially for large geometries. In our database, we have
>> geometry objects up to 20MB per piece. Also, in PostGIS, send/receive
>> binary representation differs slightly from internal representation (and
>> input/output text is even more overhead).
>
> Ok. We are probably talking about different things. I'm referring to the
> internal C-functions that are executed directly in the backend.

I talked about those backend functions that are declared in CREATE TYPE
statement, which create the canonical text or binary representation
which is sent over to clients (or received from them). This also are the
representations which jdbc works on.

For primitive types, the binary rep equals the internal rep (minus
endianness?), and such conversion is cheap. But this is different for
other types, especially those which are huge in size.

BTW, while loading the PLJava sources from CVS into Eclipse, I found a
small problem in Backend.java, line 127 (the non-1.5 version):

if(perm.getActions().contains("write") &&
perm.getName().startsWith("java."))

In Java 1.4 (I tried sun and ibm ones), String has no contains() method.

Markus

--
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios@logi-track.com | www.logi-track.com

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCDLXlOVWsnapT9i0RAnHPAJ94pFRujg0Cy/nSLRbu2MKfdqF9QQCg5etT
VcpIO2eHn8vOwwTXZAXOUZ4=
=ebVG
-----END PGP SIGNATURE-----