Re: Scaling up deferred unique checks and the after trigger queue - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Scaling up deferred unique checks and the after trigger queue
Date
Msg-id 603c8f070910261042o7191fc8pe4ae3014670c8a24@mail.gmail.com
Whole thread Raw
In response to Re: Scaling up deferred unique checks and the after trigger queue  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Mon, Oct 26, 2009 at 9:46 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Mon, 2009-10-26 at 13:28 +0000, Dean Rasheed wrote:
>
>> It works for all kinds of trigger events,
>> and is intended as a complete drop-in replacement for the after
>> triggers queue.
>
>> > All of those seem false in the general case. What will you do?
>>
>> At this point I'm looking for more feedback as to whether any of this
>> is a show-stopper, before I expend more effort on this patch.
>
> I see no show stoppers, only for you to look at ways of specifying that
> this optimization is possible for particular cases. I think we might be
> able to make the general statement that it will work for all after
> triggers that execute STABLE or IMMUTABLE functions. I don't think we
> can assume that firing order is irrelevant for some cases, e.g. message
> queues.

Hmm.  After-trigger functions are very unlikely to really be STABLE or
IMMUTABLE, though.  Almost by definition, they'd better be modifying
some data somewhere, or there's no point.

...Robert


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Unicode UTF-8 table formatting for psql text output
Next
From: Greg Stark
Date:
Subject: Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order