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
>
> AFTER_TRIGGER_FDW_FETCH and AFTER_TRIGGER_FDW_REUSE correspond to the
> 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