Re: partitioning and identity column

Dmitry Dolgov <9erthalion6@gmail.com>

From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>, Alexander Lakhin <exclusion@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-05-06T14:01:33Z
Lists: pgsql-hackers
> On Mon, May 06, 2024 at 06:52:41PM +0530, Ashutosh Bapat wrote:
> On Sun, May 5, 2024 at 1:43 AM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
> > I had a quick look, it covers the issues mentioned above in the thread.
> > Few nitpicks/questions:
> >
> > * I think it makes sense to verify if the ptup is valid. This approach
> >   would fail if the target column of the root partition is marked as
> >   attisdropped.
> >
>
> The column is searched by name which is derived from attno of child
> partition. So it has to exist in the root partition. If it doesn't
> something is seriously wrong. Do you have a reproducer? We may want to add
> Assert(HeapTupleIsValid(ptup)) just in case. But it seems unnecessary to me.

Sure, normally it should work. I don't have any particular situation in
mind, when attisdropped might be set on a root partition, but obviously
setting it manually crashes this path. Consider it mostly as suggestion
for a more defensive implementation "just in case".

> >      Oid
> >     -getIdentitySequence(Oid relid, AttrNumber attnum, bool missing_ok)
> >     +getIdentitySequence(Relation rel, AttrNumber attnum, bool missing_ok)
> >      {
> >
> >     [...]
> >
> >     +           relid = llast_oid(ancestors);
> >     +           ptup = SearchSysCacheAttName(relid, attname);
> >     +           attnum = ((Form_pg_attribute) GETSTRUCT(ptup))->attnum;
> >
> > * getIdentitySequence is used in build_column_default, which in turn
> >   often appears in loops over table attributes. AFAICT it means that the
> >   same root partition search will be repeated multiple times in such
> >   situations if there is more than one identity. I assume the
> >   performance impact of this repetition is negligible?
> >
>
> I thought having multiple identity columns would be rare and hence avoided
> making code complex. Otherwise we have to get root partition somewhere in
> the caller hierarchy separately the logic much farther apart. Usually the
> ancestor entries will be somewhere in the cache

Yeah, agree, it's reasonable to expect that the case with multiple
identity columns will be rare.



Commits

  1. Fix assorted bugs related to identity column in partitioned tables

  2. Remove extra check_stack_depth() from dropconstraint_internal()

  3. Support identity columns in partitioned tables

  4. doc: Add Identity Column section under Data Definition chapter

  5. Assert that partition inherits from only one parent in MergeAttributes()

  6. doc: Decorate PostgreSQL with productname tag

  7. Fix prologue of get_partition_ancestors()