TOAST table created for partitioned tables

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