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
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
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
2014-09-01 8:54 GMT+02:00 Huang, Suya suya.hu...@au.experian.com:
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
Hi Pavel,
See output of explain (analyze,timing off), the total runtime is close to the
one enable timing.
dev=# EXPLAIN (ANALYZE, TIMING OFF) select cha_type,sum(visits) from
weekly_non_hstore a join seg1 b on a.ref_id=b.ref_id group by cha_type order
by sum(visits) desc;
Huang, Suya wrote
See output of explain (analyze,timing off), the total runtime is close to
the one enable timing.
Calling 43s close to 70s doesn't sound right...
dev=# explain (analyze, timing off) select cha_type, sum(visits) from
(select (each(visits)).key as
