Le mercredi 5 mars 2014 22:36:44 Noah Misch a écrit :
> Agreed.  More specifically, I see only two scenarios for retrieving tuples
> from the tuplestore.  Scenario one is that we need the next tuple (or pair
> of tuples, depending on the TriggerEvent).  Scenario two is that we need
> the tuple(s) most recently retrieved.  If that's correct, I'm inclined to
> rearrange afterTriggerInvokeEvents() and AfterTriggerExecute() to remember
> the tuple or pair of tuples most recently retrieved.  They'll then never
> call tuplestore_advance() just to reposition.  Do you see a problem with
> that?

I don't see any problem with that. I don't know how this would be implemented, 
but it would make sense to avoid those scans, as long as a fresh copy is 
passed to the trigger: modifications to a tuple performed in an after trigger 
should not be visible to the next one.

> I was again somewhat tempted to remove ate_tupleindex, perhaps by defining
> the four flag bits this way:
> #define AFTER_TRIGGER_DONE                            0x10000000
> #define AFTER_TRIGGER_IN_PROGRESS             0x20000000
> /* two bits describing the size of and tuple sources for this event */
> #define AFTER_TRIGGER_TUP_BITS                        0xC0000000
> #define AFTER_TRIGGER_FDW_REUSE                       0x00000000
> #define AFTER_TRIGGER_FDW_FETCH                       0x40000000
> #define AFTER_TRIGGER_1CTID                           0x80000000
> #define AFTER_TRIGGER_2CTID                           0xC0000000
> aforementioned scenarios one and two, respectively.  I think, though, I'll
> rate this as needless micro-optimization and not bother; opinions welcome.
> (The savings is four bytes per foreign table trigger event.)

I was already happy with having a lower footprint for foreign table trigger 
events than for regular trigger events, but if we remove the need for seeking 
in the tuplestore entirely, it would make sense to get rid of the index.

> Thanks,
> nm

Thanks to you.

Ronan Dunklau
http://dalibo.com - http://dalibo.org

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to