Perhaps the only way to get around the cache problem is to use an ISO-8859-x 8bit character set, but to have per table,
orper column encoding attributes. And of course, ways to access what those are, in the Postgres API. Good for speed,
butnot for easy storing of multiple language/encodings per column/table.
Gianni Mariani wrote:
> Dennis Gearon wrote:
>
>> I agree with all of that except for one caveat:
>>
>> all my reading, and just general off the cuff thinking, says that
>> processing variable width characters SIGNIFICANTLY slows an
>> application. It seems better to PROCESS fixed width characters (1,2,4
>> byte), and TRANSMIT variable width characters (avoiding the null
>> problem.)
>
>
>
> I can and have solved that problem. If you can assume utf-8 encoding
> then there are available to you a bunch o tricks that takes this problem
> away.
>
> The other problem with memory (and hence cache) utilization of a wide
> char only solution it far more significant.
> Cache effects are the primary killer for performance in an app like a
> database.
>
> Anyhow, before making any "decisions" one should do a bunch of analysis.
>
> Cheers
> G
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
