Обсуждение: TOAST table created for partitioned tables

Hi.

I used to think that $subject didn't happen, but it actually does and ends
up consuming a fixed 8192 bytes on the disk.

create table p (a int[]) partition by list (a);
CREATE TABLE

select pg_table_size('p');
 pg_table_size
---------------
          8192
(1 row)

select  pg_relation_size(c1.oid) as p_size,
        pg_relation_size(c1.reltoastrelid) as p_toast_heap_size,
        pg_relation_size(c2.oid) as p_toast_index_size
from    pg_class c1, pg_class c2, pg_index i
where   c1.relname = 'p' and
        c1.reltoastrelid = i.indrelid and
        c2.oid = i.indexrelid;
 p_size | p_toast_heap_size | p_toast_index_size
--------+-------------------+--------------------
      0 |                 0 |               8192
(1 row)

I think we should prevent this, a fix for which is implemented by the
attached patch.

Thanks,
Amit

On Tue, Jan 16, 2018 at 5:13 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> I used to think that $subject didn't happen, but it actually does and ends
> up consuming a fixed 8192 bytes on the disk.
>
> create table p (a int[]) partition by list (a);
> CREATE TABLE
>
> select pg_table_size('p');
>  pg_table_size
> ---------------
>           8192
> (1 row)
>
> select  pg_relation_size(c1.oid) as p_size,
>         pg_relation_size(c1.reltoastrelid) as p_toast_heap_size,
>         pg_relation_size(c2.oid) as p_toast_index_size
> from    pg_class c1, pg_class c2, pg_index i
> where   c1.relname = 'p' and
>         c1.reltoastrelid = i.indrelid and
>         c2.oid = i.indexrelid;
>  p_size | p_toast_heap_size | p_toast_index_size
> --------+-------------------+--------------------
>       0 |                 0 |               8192
> (1 row)

Aargh.  Will apply this patch break pg_upgrade from v10?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Wed, Jan 17, 2018 at 5:32 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Jan 16, 2018 at 5:13 AM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> I used to think that $subject didn't happen, but it actually does and ends
>> up consuming a fixed 8192 bytes on the disk.
>>
>> create table p (a int[]) partition by list (a);
>> CREATE TABLE
>>
>> select pg_table_size('p');
>>  pg_table_size
>> ---------------
>>           8192
>> (1 row)
>>
>> select  pg_relation_size(c1.oid) as p_size,
>>         pg_relation_size(c1.reltoastrelid) as p_toast_heap_size,
>>         pg_relation_size(c2.oid) as p_toast_index_size
>> from    pg_class c1, pg_class c2, pg_index i
>> where   c1.relname = 'p' and
>>         c1.reltoastrelid = i.indrelid and
>>         c2.oid = i.indexrelid;
>>  p_size | p_toast_heap_size | p_toast_index_size
>> --------+-------------------+--------------------
>>       0 |                 0 |               8192
>> (1 row)
>
> Aargh.  Will apply this patch break pg_upgrade from v10?

AFAICS, it doesn't.  Partitioned tables that used to have a TOAST
table in v10 cluster will continue to have it after upgrading.
Whereas, any partitioned tables created with the patched won't have a
TOAST table.

Thanks,
Amit

Amit Langote <amitlangote09@gmail.com> writes:
> On Wed, Jan 17, 2018 at 5:32 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Aargh.  Will apply this patch break pg_upgrade from v10?

> AFAICS, it doesn't.  Partitioned tables that used to have a TOAST
> table in v10 cluster will continue to have it after upgrading.
> Whereas, any partitioned tables created with the patched won't have a
> TOAST table.

Yeah, pg_upgrade already has to cope with cases where the newer version
thinks a table needs a toast table when the older version didn't, or
vice versa.  This looks like it ought to fall into that category.
Not that testing it wouldn't be a good idea.

            regards, tom lane

On Tue, Jan 16, 2018 at 11:38:58PM -0500, Tom Lane wrote:
> Yeah, pg_upgrade already has to cope with cases where the newer version
> thinks a table needs a toast table when the older version didn't, or
> vice versa.  This looks like it ought to fall into that category.
> Not that testing it wouldn't be a good idea.

As far as I can see this statement is true. If you create a parent
partition table in a v10 cluster, and then upgrade to HEAD with this
patch applied, you'll be able to notice that the relation still has its
toast table present, while newly-created parent partitions would have
nothing. (Just tested, I didn't review the patch in details).
--
Michael

On Wed, Jan 17, 2018 at 1:51 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Jan 16, 2018 at 11:38:58PM -0500, Tom Lane wrote:
>> Yeah, pg_upgrade already has to cope with cases where the newer version
>> thinks a table needs a toast table when the older version didn't, or
>> vice versa.  This looks like it ought to fall into that category.
>> Not that testing it wouldn't be a good idea.
>
> As far as I can see this statement is true. If you create a parent
> partition table in a v10 cluster, and then upgrade to HEAD with this
> patch applied, you'll be able to notice that the relation still has its
> toast table present, while newly-created parent partitions would have
> nothing. (Just tested, I didn't review the patch in details).

Thanks for checking.  I too checked that pg_upgrading v10 cluster
containing partitioned tables that have a TOAST table attached to it
works normally and like Michael says, the TOAST table remains.

Thanks,
Amit

On Wed, Jan 17, 2018 at 1:03 AM, Amit Langote <amitlangote09@gmail.com> wrote:
> On Wed, Jan 17, 2018 at 1:51 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Tue, Jan 16, 2018 at 11:38:58PM -0500, Tom Lane wrote:
>>> Yeah, pg_upgrade already has to cope with cases where the newer version
>>> thinks a table needs a toast table when the older version didn't, or
>>> vice versa.  This looks like it ought to fall into that category.
>>> Not that testing it wouldn't be a good idea.
>>
>> As far as I can see this statement is true. If you create a parent
>> partition table in a v10 cluster, and then upgrade to HEAD with this
>> patch applied, you'll be able to notice that the relation still has its
>> toast table present, while newly-created parent partitions would have
>> nothing. (Just tested, I didn't review the patch in details).
>
> Thanks for checking.  I too checked that pg_upgrading v10 cluster
> containing partitioned tables that have a TOAST table attached to it
> works normally and like Michael says, the TOAST table remains.

I have committed your patch.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 2018/03/23 2:51, Robert Haas wrote:
> On Wed, Jan 17, 2018 at 1:03 AM, Amit Langote <amitlangote09@gmail.com> wrote:
>> On Wed, Jan 17, 2018 at 1:51 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> On Tue, Jan 16, 2018 at 11:38:58PM -0500, Tom Lane wrote:
>>>> Yeah, pg_upgrade already has to cope with cases where the newer version
>>>> thinks a table needs a toast table when the older version didn't, or
>>>> vice versa.  This looks like it ought to fall into that category.
>>>> Not that testing it wouldn't be a good idea.
>>>
>>> As far as I can see this statement is true. If you create a parent
>>> partition table in a v10 cluster, and then upgrade to HEAD with this
>>> patch applied, you'll be able to notice that the relation still has its
>>> toast table present, while newly-created parent partitions would have
>>> nothing. (Just tested, I didn't review the patch in details).
>>
>> Thanks for checking.  I too checked that pg_upgrading v10 cluster
>> containing partitioned tables that have a TOAST table attached to it
>> works normally and like Michael says, the TOAST table remains.
> 
> I have committed your patch.

Thank you!

Regards,
Amit