Re: Scaling up deferred unique checks and the after trigger queue

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Dean Rasheed <dean(dot)a(dot)rasheed(at)googlemail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Scaling up deferred unique checks and the after trigger queue
Date: 2009-10-26 17:42:52
Message-ID: 603c8f070910261042o7191fc8pe4ae3014670c8a24@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 26, 2009 at 9:46 AM, Simon Riggs <simon(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2009-10-26 17:58:14 Re: Endgame for all those SELECT FOR UPDATE changes: fix plan node order
Previous Message Tom Lane 2009-10-26 17:33:19 Re: Unicode UTF-8 table formatting for psql text output