Re: Please help with binary file
От | Fernando Nasser |
---|---|
Тема | Re: Please help with binary file |
Дата | |
Msg-id | 3F043B77.7060800@redhat.com обсуждение исходный текст |
Ответ на | Re: Please help with binary file (Kris Jurka <books@ejurka.com>) |
Список | pgsql-jdbc |
Oliver Jowett wrote: It is this one: http://archives.postgresql.org/pgsql-jdbc/2003-05/msg00127.php Patch summary: use a temporary LO to stream bytea values to the server without needing to transform them to a potentially large intermediate string representation (I think). Correct. You need almost no extra memory, like when dealing with the LO types. But you will have to VACUUM your pg_largeobject table periodically, which may be inconvenient. What impact does this patch have on latency? We do many small transactions each dealing with small bytea fields, so if this patch ends up doing additional round-trips per insert, it's going to hurt. You are absolutely right. Barry has suggested that I change it and only do it if the data is above a certain length. We set it at 16K. But I did not implement it because we decided not to add it to the community driver as the 7.4 backend will provide us with a mechanism for handling these cases (without a staging area). From a quick look at your patch, though, it appears to only touch setBinaryStream()? From memory, we use setBytes(), so this may not be an issue for us (although we'd like to keep the option of using setBinaryStream()). Yes, the idea was use setBinaryStream() if you want to use this method (we cannot do much for setBytes() anyway as we need the stream). Of course, Barry's suggestion makes it much better as it allows one to use setBinaryStream() for small data as well. If there is a lot of interest in this fix for 7.3 and 7.2 backends, and you can convince Barry to incorporate it (with his proposed changes) in the driver, I can ask for time to get it in shape for submission. But I won't be able to do it unless it goes into the main line of code -- I already have to work on the 7.4 version (V3 protocol). Best regards, Fernando -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9
В списке pgsql-jdbc по дате отправления: