Re: [HACKERS] Custom compression methods
От | Tomas Vondra |
---|---|
Тема | Re: [HACKERS] Custom compression methods |
Дата | |
Msg-id | e3378c06-d805-a3f5-6ea7-af2a2417361e@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Custom compression methods (Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>) |
Ответы |
Re: [HACKERS] Custom compression methods
|
Список | 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
В списке pgsql-hackers по дате отправления: