On Tue, Aug 7, 2012 at 3:22 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> 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
>> 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
>> 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.
In response to
pgsql-performance by date
|Next:||From: Stefan Keller||Date: 2012-08-08 00:07:48|
|Subject: Re: Slow query: Select all buildings that have >1
pharmacies and >1 schools within 1000m|
|Previous:||From: Jeff Janes||Date: 2012-08-07 22:22:55|
|Subject: Re: Is drop/restore trigger transactional?|