From: | Christopher Browne <cbbrowne(at)gmail(dot)com> |
---|---|
To: | Marc Mamin <M(dot)Mamin(at)intershop(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Another hstore_type idea |
Date: | 2011-12-23 18:46:04 |
Message-ID: | CAFNqd5W=9PHVN30sSF8j-To6rq9fRexfFfVjdt-MW+OAg6vujQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Dec 23, 2011 at 7:06 AM, Marc Mamin <M(dot)Mamin(at)intershop(dot)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?"
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-12-23 19:16:11 | Re: patch: bytea_agg |
Previous Message | Tomas Vondra | 2011-12-23 18:40:35 | Re: WIP: explain analyze with 'rows' but not timing |