Neil Conway <[EMAIL PROTECTED]> writes:
>> (b) it can share infrastructure with the other RI triggers.
> Such as? I don't see anything it allows us to share.
Note the ri_BuildQueryKeyFull call, and the arguments thereto.
As to the notational convenience issue, I think it's good that
RI_FKey_keye
Tom Lane wrote:
Because (a) it needs all the same arguments
Well, it needs the Trigger that we're in the process of queueing, the
old tuple, the new tuple, and the updated relation. It doesn't need the
rest of the content of TriggerData. trigger.c has to manually construct
a TriggerData to p
Neil Conway <[EMAIL PROTECTED]> writes:
> Speaking of which, does anyone see a reason why RI_FKey_keyequal_upd()
> is implemented as a pseudo-trigger function -- e.g. taking a pointer to
> a TriggerData?
Because (a) it needs all the same arguments and (b) it can share
infrastructure with the oth
Tom Lane wrote:
But the check could incorporate the same transaction ID test already
in use. I think Neil is right that it'd be a win to apply the test
before enqueueing the trigger instead of after.
Speaking of which, does anyone see a reason why RI_FKey_keyequal_upd()
is implemented as a ps
On Thu, 26 May 2005, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Thu, 26 May 2005, Tom Lane wrote:
> >> The thoughts I've had about special-casing RI events to save memory
> >> have to do with the idea of lossy storage.
>
> > One problem with that is that it works for the c
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Thu, 26 May 2005, Tom Lane wrote:
>> The thoughts I've had about special-casing RI events to save memory
>> have to do with the idea of lossy storage.
> One problem with that is that it works for the constraint check but not
> for referential actions,
On Thu, 26 May 2005, Tom Lane wrote:
> The thoughts I've had about special-casing RI events to save memory
> have to do with the idea of lossy storage. As you accumulate more
> per-row events, at some point it becomes more efficient to forget
> the individual rows and just reapply the original fu
On Thu, 26 May 2005, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> >> Okay, I can't think of cases even with triggers and the like where
> >> removing the check on equal valued rows would give appreciably different
> >> results, but I haven't thought too hard about it.
>
> > Err,
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> Okay, I can't think of cases even with triggers and the like where
>> removing the check on equal valued rows would give appreciably different
>> results, but I haven't thought too hard about it.
> Err, except the case that Tom mentions in his message.
On Thu, 26 May 2005, Stephan Szabo wrote:
> On Fri, 27 May 2005, Neil Conway wrote:
>
> > Stephan Szabo wrote:
> > > Are you sure? RI_FKey_Check seems to have a section on
> > > TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the
> > > old row wasn't part of this transaction
On Fri, 27 May 2005, Neil Conway wrote:
> Stephan Szabo wrote:
> > Are you sure? RI_FKey_Check seems to have a section on
> > TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the
> > old row wasn't part of this transaction.
>
> Well, regardless of how RI_FKey_Check() itself wo
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Are you sure? RI_FKey_Check seems to have a section on
> TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the
> old row wasn't part of this transaction. I'm not sure why it's doing the
> transaction id check, but it looks like it wil
On Thu, 26 May 2005, Stephan Szabo wrote:
> On Thu, 26 May 2005, Neil Conway wrote:
>
> > (2) For per-row RI triggers of all kinds, we save the trigger under
> > CurTransactionContext and invoke it at the end of the current query.
> > There is not even overflow to disk (the report that prompted me
Stephan Szabo wrote:
Are you sure? RI_FKey_Check seems to have a section on
TRIGGER_FIRED_BY_UPDATE which seems to check if the keys are equal if the
old row wasn't part of this transaction.
Well, regardless of how RI_FKey_Check() itself works, ISTM there is no
need to enqueue the RI trigger i
On Thu, 26 May 2005, Neil Conway wrote:
> I spent a little while looking into a performance issue with a large
> UPDATE on a table with foreign keys. A few questions:
>
> (1) When a PK table is updated, we skip firing the per-row UPDATE RI
> triggers if none of the referenced columns in the PK tab
I spent a little while looking into a performance issue with a large
UPDATE on a table with foreign keys. A few questions:
(1) When a PK table is updated, we skip firing the per-row UPDATE RI
triggers if none of the referenced columns in the PK table have been
modified. However, AFAICS we do n
16 matches
Mail list logo
