Yes, I'll go for pure TEXT objects. I read this performance tip about TEXT on the docs, makes me like Postgres :-)
Anyway, I just checked alternative types for character data, and tested JDBC type LONGVARCHAR, and now the data is being stored directly to the TEXT field. Just configuration after all, living and learning... better get rid of those large objects.
Thanks Ray!
On Fri, Oct 2, 2009 at 9:33 AM, Raymond O'Donnell
<rod@iol.ie> wrote:
On 02/10/2009 12:55, mad rug wrote:
> I really don't know. JDBC communication is being handled by a JDO
> library, so I don't know which one is doing this, but I suspect about
> JDO. I feel like asking about it in the forums there, but then I'd like
> to know: is there any performance (disk, read/write speed...) difference
> between storing large text data as TEXT and large object? I believe this
> indirection of storing as large object could mean a small overhead,
> unless it is somehow better using large objects (just then why use TEXT
> for some data that is just a couple of chars?)
Well, as I said I don't really know anything about large objects, but
I'd suspect that you're right about the performance hit with them.
However, TEXT is the recommended type for *any* text storage, big or
small: there's no difference performance-wise between TEXT and
VARCHAR(n), and if anything I'd guess that VARCHAR is a (very very) tiny
bit slower because of the length check. Large object is intended for
binary data.
Ray.
------------------------------------------------------------------
Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland
rod@iol.ie Galway Cathedral Recitals:
http://www.galwaycathedral.org/recitals ------------------------------------------------------------------
