Re: transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Tue, May 16, 2017 at 4:50 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> On Wed, May 17, 2017 at 9:20 AM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:
>> On Wed, May 10, 2017 at 7:02 AM, Thomas Munro
>> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>>> On Wed, May 10, 2017 at 11:10 PM, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>>>> 2. If you attach a row-level trigger with transition tables to any
>>>> inheritance child, it will see transition tuples from all tables in
>>>> the inheritance hierarchy at or below the directly named table that
>>>> were modified by the same statement, sliced so that they appear as
>>>> tuples from the directly named table.
>>>
>>> Of course that's a bit crazy, not only for trigger authors to
>>> understand and deal with, but also for plan caching: it just doesn't
>>> really make sense to have a database object, even an ephemeral one,
>>> whose type changes depending on how the trigger was invoked, because
>>> the plans stick around.
>>
>> The patch to add transition tables changed caching of a trigger
>> function to key on the combination of the function and the target
>> relation, rather than having one cache entry regardless of the
>> target table.
>
> Right. That works as long as triggers always see tuples in the format
> of the relation that they're attached to, and I think that's the only
> sensible choice. The problem I was thinking about was this: We have
> only one pair of tuplestores and in the current design it holds tuples
> of a uniform format, yet it may (eventually) need to be scanned by a
> statement trigger attached to a the named relation AND any number of
> row triggers attached to children with potentially different formats.
> That implies some extra conversions are required at scan time. I had
> a more ambitious patch that would deal with sone of that by tracking
> storage format and scan format separately (next time your row trigger
> is invoked the scan format will be the same but the storage format may
> be different depending on which relation you named in a query), but
> I'm putting that to one side for this release. That was a bit of a
> rabbit hole, and there are some tricky design questions about tuple
> conversions (to behave like DB2 with subtables may even require
> tuplestore with per-tuple type information) and also the subset of
> rows that each row trigger should see (which may require extra tuple
> origin metadata or separate tuplestores).

Yeah, I wish this had surfaced far earlier, but I missed it and none
of the reviews prior to commit caught it, either. :-( It seems too
big to squeeze into v10 now. I just want to have that general
direction in mind and not paint ourselves into any corner that makes
it hard to get there in the next release.

> I'm about to post a much simpler patch that collects uniform tuples
> from children, addressing the reported bug, and simply rejects
> transition tables on row-triggers on tables that are in either kind of
> inheritance hierarchy. More soon...

I agree that we can safely go that far, but not farther. Thanks!

--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/