<commit_before># istore

The idea of istore is to have an integer based hstore (thus the name) which
supports operators like + and aggregates like SUM.

The textual representation of an istore is the same as for hstore
e.g.

    "-5"=>"-25", "0"=>"10", "5"=>"0", "100"=>"30"`

On istore both key and value are represented and stored as integer. The extension
comes with two types `istore` and `bigistore` the former having `int` and the
latter `bigint` as values, keys are `int` for both.

The use case an optimization for istore is an analytical workload.
Think of it as showing distributions of whatever can be represented as integer.

### Example

Say you have an event log table where you'd aggregate events with some id  and
segmentation by date.

```pgsql
    CREATE TABLE event_log AS
    SELECT
      d::date as date,
      j as segment,
      i as id, (random()*1000)::int as count,
      (random()*100000)::int as revenues
    FROM
      generate_series(1,50) i,
      generate_series(1,1000) j,
      generate_series(current_date - 99, current_date, '1 day') d;
```

Using istore you would use the id as key and count / revenues as values.

```pgsql<commit_msg>Readme typo<commit_after># istore

The idea of istore is to have an integer based hstore (thus the name) which
supports operators like + and aggregates like SUM.

The textual representation of an istore is the same as for hstore
e.g.

    "-5"=>"-25", "0"=>"10", "5"=>"0", "100"=>"30"`

On istore both keys and values are represented and stored as integer. The extension
comes with two types `istore` and `bigistore` the former having `int` and the
latter `bigint` as values, keys are `int` for both.

The use case an optimization for istore is an analytical workload.
Think of it as showing distributions of whatever can be represented as integer.

### Example

Say you have an event log table where you'd aggregate events with some id  and
segmentation by date.

```pgsql
    CREATE TABLE event_log AS
    SELECT
      d::date as date,
      j as segment,
      i as id, (random()*1000)::int as count,
      (random()*100000)::int as revenues
    FROM
      generate_series(1,50) i,
      generate_series(1,1000) j,
      generate_series(current_date - 99, current_date, '1 day') d;
```

Using istore you would use the id as key and count / revenues as values.

```pgsql
{'fraction_non_alphanumeric': 0.09129692832764505, 'fraction_numerical': 0.02901023890784983, 'mean_word_length': 3.6161417322834644, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 11, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1132658', 'n_tokens_mistral': 776, 'n_tokens_neox': 699, 'n_words': 334}