thanks Craig - we are doing some testing with some of your ideas
now Hopefully we can get this solved so using triggers doesn't
cause so much contention. I also understand that foreign keys can also
cause some of these issues. Do you have any thoughts on that?
thanks again, Maria Wilso
On 09/28/2011 08:54 PM, Maria L. Wilson wrote:
UPDATE dataset
SET gracount = gracount + 1
WHERE dataset.inv_id = NEW.inv_id;
That'll serialize all transactions that touch the same inv_id, so only
one may run at once. The second and subsequent ones will block waiting
for an update lock on the
Gilberto Castillo Martínez wrote:
>> CREATE OR REPLACE FUNCTION increment_dataset_granule_count()
>> RETURN NULL;
> Replace RETURN NULL for RETURN NEW
That won't matter for an AFTER trigger:
http://www.postgresql.org/docs/9.0/interactive/trigger-definition.html
says:
| The ret
El mié, 28-09-2011 a las 08:54 -0400, Maria L. Wilson escribió:
> Hi all
>
> I would like to start a dialogue and hear general feedback about the
> use of constraint triggers in postgres (8.4.5).
>
> Our overall issue is that using general triggers is causing slow
> inserts (from locking is
Hi all
I would like to start a dialogue and hear general feedback about the use
of constraint triggers in postgres (8.4.5).
Our overall issue is that using general triggers is causing slow inserts
(from locking issues) in our database. Here are some details:
A little background (jboss/
I'm looking for a way to create a trigger function that gets
called once per transaction as an AFTER EVENT.
Because there is no option for creating such
a trigger function I was looking at the "create constraint trigger"
command.
My approach would be to check the current transaction id to
