From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Ildus Kurbangaliev <i(dot)kurbangaliev(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Ildar Musin <i(dot)musin(at)postgrespro(dot)ru> |
Subject: | Re: [HACKERS] Custom compression methods |
Date: | 2017-11-25 01:13:41 |
Message-ID: | e3378c06-d805-a3f5-6ea7-af2a2417361e@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 11/24/2017 10:38 AM, Ildus Kurbangaliev wrote:
> ...
> That means compressed datums now in the column with storage
> specified as external. I'm not sure that's a bug or a feature.
>
Interesting. Never realized it behaves like this. Not sure if it's
intentional or not (i.e. bug vs. feature).
> Lets insert them usual way:
>
> delete from t2;
> insert into t2 select repeat(md5(i::text),300) from
> generate_series(1,100000) s(i);
> \d+
>
> List of relations
> Schema | Name | Type | Owner | Size | Description
> --------+------+-------+-------+---------+-------------
> public | t1 | table | ildus | 18 MB |
> public | t2 | table | ildus | 1011 MB |
>
> Maybe there should be more common solution like comparison of
> attribute properties?
>
Maybe, not sure what the right solution is. I just know that if we allow
inserting data into arbitrary tables without recompression, we may end
up with data that can't be decompressed.
I agree that the behavior with extended storage is somewhat similar, but
the important distinction is that while that is surprising the data is
still accessible.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2017-11-25 01:20:02 | Re: [HACKERS] ginInsertCleanup called from vacuum could still miss tuples to be deleted |
Previous Message | Craig Ringer | 2017-11-24 23:42:30 | Re: Add RANGE with values and exclusions clauses to the Window Functions |