Thread: Another hstore_type idea

<p dir="LTR"><span lang="de"></span><span lang="en-us"><font face="Calibri">Hello,</font></span><p dir="LTR"><span
lang="en-us"><fontface="Calibri">after reading the thread on "Typed hstore proposal", I wonder if another minded
extensionof hstore would be benefical:</font></span><p dir="LTR"><span lang="en-us"><font face="Calibri">add additional
hstoretypes with numerical data type for the values.</font></span><p dir="LTR"><span lang="de"></span><span
lang="en-us"><fontface="Calibri">e.g.</font></span><span lang="de"></span><span lang="en-us"><font
face="Calibri">:</font></span><spanlang="de"></span><span lang="en-us"> <font face="Calibri"> hstore_float : text ->
float</font></span><pdir="LTR"><span lang="de"></span><span lang="en-us"></span><p dir="LTR"><span lang="en-us"><font
face="Calibri">Thisshould allow to add some nice aggregation function on these hstore, e.g.</font></span><p
dir="LTR"><spanlang="en-us"><font face="Calibri">select distinct_sum(x) from</font></span><p dir="LTR"><span
lang="en-us"><fontface="Calibri">(</font></span><p dir="LTR"><span lang="en-us"><font face="Calibri">  a -> 1   b
->5</font></span><p dir="LTR"><span lang="en-us"><font face="Calibri">  a -> 3   c -> 2</font></span><p
dir="LTR"><spanlang="en-us"><font face="Calibri">)</font></span><p dir="LTR"><span lang="en-us"><font
face="Calibri">=></font></span><pdir="LTR"><span lang="en-us"><font face="Calibri">a -> 4  b -> 5  c ->
2</font></span><br/><p dir="LTR"><span lang="en-us"><font face="Calibri">I have a small case where I'm doing this with
acustom type (text, float) , but with poor performances.</font></span><p dir="LTR"><span lang="en-us"><font
face="Calibri">Iguess that such an extension would make sense if it were to bring a significant performance gain
comparedto the custom type approach.</font></span><p dir="LTR"><span lang="en-us"><font face="Calibri">best regards and
MerryChristmas,</font></span><p dir="LTR"><span lang="de"><font face="Calibri">Marc Mamin</font></span><span
lang="de"></span>

On Fri, Dec 23, 2011 at 7:06 AM, Marc Mamin <M.Mamin@intershop.de> 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?"