Re: Patch to support SEMI and ANTI join removal

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <jim(at)nasby(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch to support SEMI and ANTI join removal
Date: 2014-09-25 12:36:33
Message-ID: 54240C51.8040304@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09/16/2014 01:20 PM, David Rowley wrote:
> + /*
> + * We mustn't allow any joins to be removed if there are any pending
> + * foreign key triggers in the queue. This could happen if we are planning
> + * a query that has been executed from within a volatile function and the
> + * query which called this volatile function has made some changes to a
> + * table referenced by a foreign key. The reason for this is that any
> + * updates to a table which is referenced by a foreign key constraint will
> + * only have the referencing tables updated after the command is complete,
> + * so there is a window of time where records may violate the foreign key
> + * constraint.
> + *
> + * Currently this code is quite naive, as we won't even attempt to remove
> + * the join if there are *any* pending foreign key triggers, on any
> + * relation. It may be worthwhile to improve this to check if there's any
> + * pending triggers for the referencing relation in the join.
> + */
> + if (!AfterTriggerQueueIsEmpty())
> + return false;

Hmm. This code runs when the query is planned. There is no guarantee
that there won't be after triggers pending when the query is later
*executed*.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-09-25 12:38:51 Re: add modulo (%) operator to pgbench
Previous Message Gregory Smith 2014-09-25 11:37:39 Re: proposal: rounding up time value less than its unit.