Re: jdbc driver performance TODO

In my opinion, improvements could be made in the encoding/decoding of
the protocole messages (Ie the PGStream class).
From what I have seen thanks to a profiler some methods are over
invoked, and the numeric encoding is not as efficient as it could be.
That numeric encoding/decoding is used very often, even for the
protocole purposes, not only for data encoding.

Furthermore, it would be interesting not to use the java BufferedStream
implementation, and use a specific one so as to directly manage and
access the buffer.

From the driver point of view, this is the core part to optimize since
everything starts or goes from/through this part (the protocole encoding).

I use a driver I have optimized, and submitted these obervations a
couple of time to the list, but I'm really sorry I can't contribute more
for a long time I'm afraid
Nevertheless, anyone that would look into these parts of the code could
make that optimisations again as they are quite simple to achieve.

Regards.

Bucky Jordan a écrit :

>My first vote would go to adding support for COPY. (Where would I find a
>design doc for this if one exists? I'm sort of curious how this will
>work..)
>
>My other is more of a question relating to parameterized statements and
>prepared statements, so I'm sending it in another post since I'm not
>sure if it qualifies as a TO-DO request.
>
>Thanks,
>
>Bucky
>
>
>
>
>
>>-----Original Message-----
>>From: pgsql-jdbc-owner(at)postgresql(dot)org [mailto:pgsql-jdbc-
>>owner(at)postgresql(dot)org] On Behalf Of Simon Riggs
>>Sent: Friday, October 27, 2006 6:58 PM
>>To: pgsql-jdbc(at)postgresql(dot)org
>>Subject: [JDBC] jdbc driver performance TODO
>>
>>I'm interested in updating the performance TODO list for the jdbc
>>driver. I want to refresh the TODO list with any new items people are
>>aware of, plus make sure each item has a link to an agreed design if
>>
>>
>one
>
>
>>exists.
>>
>>Forgive me for the observation, but the current list does seem to be a
>>little out of date:
>>- Add statement pooling to take advantage of server prepared
>>
>>
>statements.
>
>
>>- Allow scrollable ResultSets to not fetch all results in one batch.
>>- Allow refcursor ResultSets to not fetch all results in one batch.
>>- Allow binary data transfers for all datatypes not just bytea.
>>
>>Could I shake the tree for any new performance suggestions? Or maybe
>>
>>
>not
>
>
>>new exactly, but just not listed. Lots of detail please....
>>
>>--
>> Simon Riggs
>> EnterpriseDB http://www.enterprisedb.com
>>
>>
>>
>>---------------------------(end of
>>
>>
>broadcast)---------------------------
>
>
>>TIP 3: Have you checked our extensive FAQ?
>>
>> http://www.postgresql.org/docs/faq
>>
>>
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: don't forget to increase your free space map settings
>
>