Re: bytea encode performance issues

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: bytea encode performance issues
Дата
Msg-id b42b73150808062153i78a6fc8r5e612948c00286d3@mail.gmail.com
обсуждение исходный текст
Ответ на Re: bytea encode performance issues  (Sim Zacks <sim@compulab.co.il>)
Ответы Re: bytea encode performance issues
Список pgsql-general
On Wed, Aug 6, 2008 at 9:16 AM, Sim Zacks <sim@compulab.co.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

В списке pgsql-general по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: lossing pg_stat's data
Следующее
От: "Pavel Stehule"
Дата:
Сообщение: Re: Invocation overhead for procedural languages