Re: Partitioned tables and relfilenode

On 10 February 2017 at 06:19, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:

> the "right thing" here being that the
> command's code either throws an error or warning (in some cases) if the
> specified table is a partitioned table or ignores any partitioned tables
> when it reads the list of relations to process from pg_class.

This is a massive assumption and deserves major discussion.

My expectation is that "partitioned tables" are "tables". Anything
else seems to fly in the face of both the SQL Standard and the POLA
principle for users coming from other database systems.

IMHO all the main actions should all "just work" not throw errors.

> Commands
> that need to be taught about this are vacuum, analyze, truncate, and alter
> table. Specifically:
>
> - In case of vacuum, specifying a partitioned table causes a warning

Why not vacuum all partitions?

> - In case of analyze, we do not throw an error or warning but simply
> avoid calling do_analyze_rel() *non-recursively*. Further in
> acquire_inherited_sample_rows(), any partitioned tables in the list
> returned by find_all_inheritors() are skipped.

Why not analyze all partitions?

> - In case of truncate, only the part which manipulates table's physical
> storage is skipped for partitioned tables.

Truncate all partitions

> - ATRewriteTables() skips on the AlteredTableInfo entries for partitioned
> tables, because there is nothing to be done.
>
> - Since we cannot create indexes on partitioned tables anyway, there is
> no need to handle cluster and reindex (they throw a meaningful error
> already due to the lack of indexes.)

Create index on all partitions

> Thoughts, comments?

We already have Inheritance. Anybody that likes that behaviour can use it.

Most people don't like that behaviour and wish to see change. They
want the same behaviour as they get from other database products where
a partitioned table is a table and you can do stuff to it just like
other tables. We have the opportunity to change things here and we
should do so.

(It also seems like wasted effort to try to remove the overhead caused
by a parent table for partitioning. Why introduce a special case to
save a few bytes? Premature optimization, surely?)

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services