Thank you Pavel.
The cost of unpacking hstore comparing to non-hstore could be calculated by:
Seq scan on hstore table + hash join with seg1 table:
Hstore: 416.741+ 34619.879 =~34 seconds
Non-hstore: 8858.594 +26477.652 =~ 34 seconds
The subsequent hash-aggregate and sort operation should be work
Hi
In this use case hstore should not help .. there is relative high overhead
related with unpacking hstore -- so classic schema is better.
Hstore should not to replace well normalized schema - it should be a
replace for some semi normalized structures as EAV.
Hstore can have some profit from TO
Hi ,
I'm tweaking table layout to get better performance of query. One table doesn't
use hstore but expand all metrics of cha_type to different rows. The other
table has hstore for metrics column as cha_type->metrics so it has less records
than the first one.
I would be expecting the query on
