Re: Is drop/restore trigger transactional? - Mailing list pgsql-performance

From Craig James
Subject Re: Is drop/restore trigger transactional?
Date
Msg-id CAFwQ8rfweNcWU_7GUqvs9rhScJPhwT2GjkFHYqxRWRmFCuo9Ug@mail.gmail.com
Whole thread Raw
In response to Re: Is drop/restore trigger transactional?  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-performance
On Tue, Aug 7, 2012 at 3:22 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Tue, Aug 7, 2012 at 2:39 PM, Craig James <cjames@emolecules.com> wrote:
>> On Tue, Aug 7, 2012 at 1:45 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
>>> On Tue, Aug 7, 2012 at 1:15 PM, Merlin Moncure <mmoncure@gmail.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.

Thanks for the ideas.  I think I have something to work with.

Craig James

pgsql-performance by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Is drop/restore trigger transactional?
Next
From: Stefan Keller
Date:
Subject: Re: Slow query: Select all buildings that have >1 pharmacies and >1 schools within 1000m