Re: jdbc driver performance TODO - Mailing list pgsql-jdbc

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@postgresql.org [mailto:pgsql-jdbc-
owner@postgresql.org] On Behalf Of Simon Riggs
Sent: Friday, October 27, 2006 6:58 PM
To: pgsql-jdbc@postgresql.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