Re: Help with bulk read performance

От: Nick Matheson
Тема: Re: Help with bulk read performance
Дата: ,
Msg-id: 4D0B6ADF.7050303@noaa.gov
(см: обсуждение, исходный текст)
Ответ на: Re: Help with bulk read performance  ("Pierre C")
Список: pgsql-performance

Скрыть дерево обсуждения

Help with bulk read performance  (Dan Schaffer, )
 Re: Help with bulk read performance  (Jim Nasby, )
 Re: Help with bulk read performance  (Andy Colson, )
  Re: Help with bulk read performance  (Jim Nasby, )
   Re: Help with bulk read performance  (Andy Colson, )
    Re: Help with bulk read performance  (Nick Matheson, )
    Re: Help with bulk read performance  (Dan Schaffer, )
     Re: Help with bulk read performance  ("Pierre C", )
      Re: Help with bulk read performance  (Nick Matheson, )
 Re: Help with bulk read performance  (Jim Nasby, )
 Re: Help with bulk read performance  (Krzysztof Nienartowicz, )

Pierre-

I agree with your observation of float <-> text conversion costs, but in
this case Dan is talking about storing the raw float data (ie: 4 bytes
per float) in a bytea array so there is only the conversion from java
float[n] to java byte[4*n] which is not nearly as costly as float <->
text conversion (especially if you leave it in architecture byte order).

Nick
>
>> If the data are stored as a byte array but retrieve into a ResultSet,
>> the unpacking time goes up by an order of magnitude and the
>> observed total throughput is 25 MB/s.  If the data are stored in a
>> Postgres float array and unpacked into a byte stream, the
>> observed throughput is 20 MB/s.
>
>
> float <-> text conversions are very slow, this is in fact due to the
> mismatch between base-2 (IEEE754) and base-10 (text) floating point
> representation, which needs very very complex calculations.



В списке pgsql-performance по дате сообщения:

От: Tom Polak
Дата:
Сообщение: Re: Compared MS SQL 2000 to Postgresql 9.0 on Windows
От: Merlin Moncure
Дата:
Сообщение: Re: postgres performance tunning