pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>
Cc: pgsql-hackers@postgresql.org, Ildar Musin <i.musin@postgrespro.ru>
Subject: Re: [HACKERS] Custom compression methods
Date: Sat, 25 Nov 2017 02:13:41 +0100
Message-ID: <e3378c06-d805-a3f5-6ea7-af2a2417361e@2ndquadrant.com> (raw)
In-Reply-To: <20171124123800.034c9208@wp.localdomain>
References: <20170907194236.4cefce96@wp.localdomain>
	<20170912175505.4afa11fd@wp.localdomain>
	<20171102152836.60c041e4@wp.localdomain>
	<20171114162356.52e3d388@wp.localdomain>
	<62e46a47-08a8-6e06-5e4f-6f52e0a13202@2ndquadrant.com>
	<20171121174717.69ecd8f4@wp.localdomain>
	<bfb3d34e-ba74-02cb-ca2a-43344866d9fd@2ndquadrant.com>
	<20171123123849.5a686d7b@wp.localdomain>
	<57daf28d-ed76-c364-a9ca-65d0ff71a36f@2ndquadrant.com>
	<20171124123800.034c9208@wp.localdomain>

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




view thread (430+ messages)  latest in thread

Message-ID: <e3378c06-d805-a3f5-6ea7-af2a2417361e@2ndquadrant.com>
Permalink:  ../e3378c06-d805-a3f5-6ea7-af2a2417361e@2ndquadrant.com/
Also on:    postgresql.org/message-id/e3378c06-d805-a3f5-6ea7-af2a2417361e@2ndquadrant.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tomas.vondra@2ndquadrant.com, i.kurbangaliev@postgrespro.ru, i.musin@postgrespro.ru
  Subject: Re: [HACKERS] Custom compression methods
  In-Reply-To: <e3378c06-d805-a3f5-6ea7-af2a2417361e@2ndquadrant.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox