On Thu, Jun 05, 2014 at 07:44:31PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Thu, Jun 05, 2014 at 02:12:33AM +0200, Andres Freund wrote:
> >> A bit more crazy, but how about trying trying to plan joins with a added
> >> one-time qual that checks the size of the deferred trigger queue? Then
> >> we wouldn't even need special case plans.
>
> > That, too, sounds promising to investigate.
>
> Not terribly. You can't actually do join removal in such a case, so it's
> not clear to me that there's much win to be had. The planner would be at
> a loss as to what cost to assign such a construct, either.
Yes, those are noteworthy points against it.
> Moreover, what happens if the trigger queue gets some entries after the
> query starts?
Normally, the query's snapshot will hide modifications that prompted those
entries. Searching for exceptions to that rule should be part of this
development effort.
A related special case came to mind: queries running in the WHEN condition of
an AFTER ROW trigger. If the trigger in question precedes the RI triggers,
the queue will not yet evidence the triggering modification. Nonetheless,
queries in the WHEN clause will see that modification.
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com