Re: [HACKERS] Another hstore_type idea

[Christopher Browne]

On Fri, Dec 23, 2011 at 7:06 AM, Marc Mamin  wrote:
> after reading the thread on "Typed hstore proposal", I wonder if another
> minded extension of hstore would be benefical:
>
> add additional hstore types with numerical data type for the values.

I would expect the primary *performance* value in an "hstore
extension" to come from things that allow accessing data without
needing to "unbox" it.
(I remember the concept of unboxing from APL; it seems to have been
subsumed by object oriented terminology...
http://en.wikipedia.org/wiki/Object_type_%28object-oriented_programming%29#Unboxing)

The big "win" comes not as much from type matching (which seems to me
like a morass, as you'll need the zillion Postgres types to cover all
the cases) as it comes from avoiding the need to take the "blobs" of
tuple data and re-parse them.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Another hstore_type idea

[Marc Mamin]

Hello,

after reading the thread on "Typed hstore proposal", I wonder if another
minded extension of hstore would be benefical:
add additional hstore types with numerical data type for the values.

e.g.:  hstore_float : text -> float

This should allow to add some nice aggregation function on these hstore,
e.g.

select distinct_sum(x) from
(
  a -> 1   b -> 5
  a -> 3   c -> 2
)

=>

a -> 4  b -> 5  c -> 2


I have a small case where I'm doing this with a custom type (text,
float) , but with poor performances.
I guess that such an extension would make sense if it were to bring a
significant performance gain compared to the custom type approach.

best regards and Merry Christmas,

Marc Mamin