From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Craig James <cjames(at)emolecules(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Is drop/restore trigger transactional? |
Date: | 2012-08-07 22:22:55 |
Message-ID: | CAMkU=1xL6803AX2aOqSuNLDysXVAFzmMMfvc4TJSTbROuhi2rg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Aug 7, 2012 at 2:39 PM, Craig James <cjames(at)emolecules(dot)com> wrote:
> On Tue, Aug 7, 2012 at 1:45 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>> On Tue, Aug 7, 2012 at 1:15 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>>
>>> IF current_user = 'bulk_writer' THEN
>>> return new;
>>> END IF;
>>> <expensive stuff>
>>
>> I don't know Craig's case, but often the most expensive of the
>> "expensive stuff" is the bare fact of firing a trigger in the first
>> place.
>
> My use case is pretty simple: Copy some already-validated user data
> from one schema to another. Since the trigger has already been
> applied, we're guaranteed that the data is already in the form we
> want.
>
> For your amusement:
Thanks. That was probably more amusing to me in particular than to most
pgsql hackers, as I think I've been a victim of your trigger.
...
>
> Obviously this is a very expensive trigger, but one that we can drop
> in a very specific circumstance. But we NEVER want to drop it for
> everyone. It seems like a very reasonable use-case to me.
And since the query is absolutely expensive, not just expensive
relative to a no-op, then Merlin's suggestion seems entirely suitable
for your use-case.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Craig James | 2012-08-07 22:46:53 | Re: Is drop/restore trigger transactional? |
Previous Message | Merlin Moncure | 2012-08-07 22:02:31 | Re: Is drop/restore trigger transactional? |