Re: Application user name attribute on connection pool

Поиск
Список
Период
Сортировка
От John R Pierce
Тема Re: Application user name attribute on connection pool
Дата
Msg-id 4C5715E1.5060909@hogranch.com
обсуждение исходный текст
Ответ на Application user name attribute on connection pool  (<rsmogura@softperience.pl>)
Ответы Re: Application user name attribute on connection pool  (Radosław Smogura <rsmogura@softperience.eu>)
Список pgsql-general
  On 08/02/10 6:30 AM, rsmogura@softperience.pl wrote:
> I would like to ask, about your opinion about numeric type. I implemented
> binary read for numeric type in JDBC and I saw, that numeric type is stored
> inside database as array of shorts no greater then nbase (currently 10000).
> In my opinion this isn't high performance method for two reasons:
> 1. Arithmetic operations could take more time.
> 2. It's generally about JDBC and other drivers, transmitting numeric value
> is complicated and leaks performance for client side, as for long numbers
> many multiplications and additions must occur.
> I think about writing something like numeric2 which internally will be
> represented as the array of ints without nbase. In this context I would
> like to ask about your opinion
> 1. If this behaviour can be useful? I imagine performance increase on
> storing and retrieving values, similarly arithmetic should be faster.
>   (currently 10001 + 10001 requires 4 operations: 2 additions of 1, and 2
> additions of 1 from 1*10000 and carry move operations, if this value will
> be stored without nbase, with full bits then addition even in short will
> take 1 operation 10001+10001 + carry move).
> 2. Will this decrease other performances? I think that text processing
> will be much slower, but will this decrease engine performance, as the text
> conversion is required when creating type?

how would you handle scale factors?   numeric represents a BCD data
type, with a decimal fractional component.   how would you represent,
say,  10000.001  in your version?  how would you add 1.001 to 10000.01
in your binary representation?

PostgreSQL already has BIGINT aka INT8, which are 8 bytes, and can
represent integers up to like 9 billion billion (eg, 9 * 10^18).



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

Предыдущее
От: steeles@gmail.com
Дата:
Сообщение: Need help on WAL configure
Следующее
От: John R Pierce
Дата:
Сообщение: Re: solaris slow