Re: [HACKERS] Binary Cursors, and the COPY command
| От | Thomas Hallgren |
|---|---|
| Тема | Re: [HACKERS] Binary Cursors, and the COPY command |
| Дата | |
| Msg-id | thhal-0SOvhAV2AUNsrD1b21bnUVdXao4af1P@mailblocks.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Binary Cursors, and the COPY command (Oliver Jowett <oliver@opencloud.com>) |
| Список | pgsql-jdbc |
Oliver Jowett wrote: > I haven't seen the string manipulation to be much of a problem with > the current driver in the profiling I've done (it'll be quite > application specific though). And I'd have thought the stringbuffer > monitors would be essentially uncontended and cheap to enter. What are > the hotspots you see? > See below... > Also I am fairly suspicious about claims that native byte order will > make things go measurably faster. Do you have any profiling or > benchmarks to back that up? The low-level manipulation of protocol > data barely shows up on the profiles I've done. I haven't made any benchmarks and I admit that as long as the client and server runs in separate processes, the gain will be relatively small. Context switching and socket management are the real time consumers. I'm the author of PL/Java. It uses its own JDBC driver on top of SPI. The main reason for thas is that I don't want the overhead of streaming data and flipping byte order when everything is readily available in memory. When "client" and "server" resides in the same process the overhead is measurable. By using java.nio in your JDBC, I beleive it would be possible to not just use native byte ordering, but perhaps also to create a nice abstraction allowing direct access to structures in memory rather than streaming data, thus obliviate the need for my own driver. And PL/Java will never run on Java 1.3 or older :-) Do you have any opinion on that? Regards, Thomas Hallgren
В списке pgsql-jdbc по дате отправления: