According to http://archives.postgresql.org/pgsql-performance/2005-03/msg00491.php This is not true for Postgres. Read tip in
http://www.postgresql.org/docs/8.3/interactive/datatype-character.html,
Tip: There are no performance differences between these three types, apart from increased storage size when using the blank-padded
type, and a few extra cycles to check the length when storing into a length-constrained column. While character(n) has performance
advantages in some other database systems, it has no such advantages in PostgreSQL. In most situations text or character varying
should be used instead.
This is *one of* the reasons I prefer Postgres (though I did not look into
MySql details)
BTW I will commit https://issues.apache.org/jira/browse/OFBIZ-1920 if nobody
see a problem with that.
Jacques
From: "madppiper" <[EMAIL PROTECTED]>
Why even stick to Varchars? You can keep it at Char(60) - that reserves the
space within the database table, but doesn't mean that you can't enter a
10char string into it... (it's a matter of diskspace really, nothing else)
Patrick Antivackis wrote:
David is right to point out the parametric search, this is a good reason
to
keep a 100% db search for products.
About the speed, i think nobody knows who will win between lucene and a
database (and which database ;) ), but databases usually are less
efficient
with variable length index than with constant length index (and keyword is
a
varchar(60)).
Patrick
--
View this message in context:
http://www.nabble.com/Replacing-Lucene-with-Solr-tp19412826p19506954.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
