Re: Application user name attribute on connection pool - Mailing list pgsql-general

From John R Pierce
Subject Re: Application user name attribute on connection pool
Date
Msg-id 4C5715E1.5060909@hogranch.com
Whole thread Raw
In response to Application user name attribute on connection pool  (<rsmogura@softperience.pl>)
Responses Re: Application user name attribute on connection pool
List 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 by date:

Previous
From: steeles@gmail.com
Date:
Subject: Need help on WAL configure
Next
From: John R Pierce
Date:
Subject: Re: solaris slow