Table AM and DDLs

From: Mats Kindahl <mats(at)timescale(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Table AM and DDLs
Date: 2021-02-22 07:33:21
Message-ID: CA+14425cNfF=P_z5LNb3TLkunEGG5CYBKBKnTREd_RuWCS5rrA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

I am quite new to PostgreSQL so forgive me if my understanding of the code
below is wrong and please clarify what I have misunderstood.

I started to experiment with the table access method interface to see if it
can be used for some ideas I have.

For the experiment, I am using a simple in-memory table access method that
stores all the data as shared memory pages instead of disk pages. I know
there are other ways to get good performance, but this implementation is
good enough for my experiments since it tests a few things with the Table
AM interface that I am wondering about.

Now, the first question I was looking at is if it is possible to
handle DDL properly if you have a non-normal storage. Both create new
storage blocks on table creation, clean up on dropping a table as well as
handling schema changes on alter table?

Creating new blocks for a table is straightforward to implement by using
the `relation_set_new_filenode` callback where you can create new memory
blocks for a relation, but I cannot find a way to clean up those blocks
when the table is dropped nor a way to handle a change of the schema for a
table.

The `relation_set_new_filenode` is indirectly called from
`heap_create_with_catalog`, but there is no corresponding callback from
`heap_drop_with_catalog`. It also seems like the intention is that the
callback should call `RelationCreateStorage` itself (makes sense, since the
access method knows about how to use the storage), so it seems natural to
add a `relation_reset_filenode` to the table AM that is called from
`heap_drop_with_catalog` for tables and add that to the heap implementation
(see the attached patch).

Altering the schema does not seem to be covered at all, but this is
something that table access methods need to know about since it might want
to optimize the internal storage when the schema changes. I have not been
able to find any discussions around this, but it seems like a natural thing
to do with a table. Have I misunderstood how this works?

Best wishes,
Mats Kindahl
Timescale

Attachment Content-Type Size
0001-Add-callback-to-reset-filenode-to-table-access-metho.patch text/x-patch 4.3 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-02-22 07:37:12 Re: Fallback table AM for relkinds without storage
Previous Message Michael Paquier 2021-02-22 07:27:17 Re: pg_collation_actual_version() ERROR: cache lookup failed for collation 123