Re: bytea encode performance issues

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Sim Zacks" <sim(at)compulab(dot)co(dot)il>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: bytea encode performance issues
Date: 2008-08-07 04:53:31
Message-ID: b42b73150808062153i78a6fc8r5e612948c00286d3@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Aug 6, 2008 at 9:16 AM, Sim Zacks <sim(at)compulab(dot)co(dot)il> wrote:
> We are using UTF-8, and I am testing SQL-ASCII at the moment. DBMail is
> a pre-built application, so until I am ready to start playing with its
> internals I don't really have a choice about a number of its features.
> The reason for the bytea is because of the multiple encodings, I have
> suggested using SQL-ASCII to them and then it will be possible to use a
> text datatype.
> I don't know the reason for using the encode, I assumed that it was
> because bytea wouldn't take a LIKE, but I see that I was mistaken. It
> could be that in an earlier release LIKE was not supported against
> bytea, but I don't know that for sure.

I don't quite follow that...the whole point of utf8 encoded database
is so that you can use text functions and operators without the bytea
treatment. As long as your client encoding is set up properly (so
that data coming in and out is computed to utf8), then you should be
ok. Dropping to ascii is usually not the solution. Your data
inputting application should set the client encoding properly and
coerce data into the unicode text type...it's really the only
solution.

merlin

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Pavel Stehule 2008-08-07 04:57:52 Re: Invocation overhead for procedural languages
Previous Message Tom Lane 2008-08-07 03:50:57 Re: lossing pg_stat's data