Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take)
От | Kevin Grittner |
---|---|
Тема | Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take) |
Дата | |
Msg-id | CACjxUsNciYMa9ZzV8HadONwhtZx1AqJkcZ-DEGJRh+xRSAi3Qw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take) (Thomas Munro <thomas.munro@enterprisedb.com>) |
Ответы |
Re: [HACKERS] transition table behavior with inheritance appearsbroken (was: Declarative partitioning - another take)
|
Список | pgsql-hackers |
On Wed, May 10, 2017 at 7:02 AM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Wed, May 10, 2017 at 11:10 PM, Thomas Munro <thomas.munro@enterprisedb.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. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/
В списке pgsql-hackers по дате отправления: