Re: hstore - Implementation and performance issues around its operators

On Sun, Jun 19, 2011 at 2:59 PM, Stefan Keller <sfkeller(at)gmail(dot)com> wrote:
> 1. Obviously the '@>' has to be used in order to let use the GiST index.
> Why is the '->' operator not supported by GiST ('->' is actually
> mentioned in all examples of the doc.)?

Because it's not a comparison operator.

> 2. Currently the hstore elements are stored in order as they are
> coming from the insert statement / constructor.
> Why are the elements not ordered i.e. why is the hstore not cached in
> all hstore functions (like hstore_fetchval etc.)?

Putting the elements in order wouldn't really help, would it? I mean,
you'd need some kind of an index inside the hstore... which there
isn't.

> 3. In the source code 'hstore_io.c' one finds the following enigmatic
> note: "... very large hstore values can't be output. this could be
> fixed, but many other data types probably have the same issue."
> What is the max. length of a hstore (i.e. the max. length of the sum
> of all elements in text representation)?

I think that anything of half a gigabyte or more is at risk of falling
down there. But probably it's not smart to use such big hstores
anyway.

> 4. Last, I don't fully understand the following note in the hstore
> doc. (http://www.postgresql.org/docs/current/interactive/hstore.html
> ):
>> Notice that the old names are reversed from the convention
>> formerly followed by the core geometric data types!
>
> Why names? Why not rather 'operators' or 'functions'?

It's referring to the operator names.

> What does this "reversed from the convention" mean concretely?

That comment could be a little more clear, but I think what it's
saying is that hstore's old @ is like the core geometic types old ~,
and visca versa.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company