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 по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Add RANGE with values and exclusions clauses to the Window Functions
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: [HACKERS] ginInsertCleanup called from vacuum could still misstuples to be deleted