From: Amit K. <ami...@en...> - 2013-04-05 09:28:43
|
On 5 April 2013 15:03, Pavan Deolasee <pav...@gm...> wrote: > *"AFTER ROW triggers are queued for each of the rows processed, and are > then executed at then end of statement. So we need to store the OLD and NEW > rows in memory until the end of statement or until the end of transaction > in case of deferred constraint triggers. The idea is to use tuplestore for > saving them."* > > > Why is that ? Aren't after row triggers processed immediately after > processing a row in PostgreSQL ? Why do we make a significant deviation in > XC ? > They are queued immediately, but executed at the end of statement. But the execution is per row, whereas for statement AFTER triggers, it is per statement. This is PG behaviour. By the way, I did not consider that a ROW can be shared by multiple triggers so I am slightly going to change the design. > Thanks, > Pavan > > On Fri, Apr 5, 2013 at 2:38 PM, Amit Khandekar < > ami...@en...> wrote: > >> FYI .. I will use the following document to keep updating the >> implementation details for "Saving AR trigger rows in tuplestore" : >> >> >> https://docs.google.com/document/d/158IPS9npmfNsOWPN6ZYgPy91aowTUNP7L7Fl9zBBGqs/edit?usp=sharing >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Minimize network downtime and maximize team effectiveness. >> Reduce network management and security costs.Learn how to hire >> the most talented Cisco Certified professionals. Visit the >> Employer Resources Portal >> http://www.cisco.com/web/learning/employer_resources/index.html >> _______________________________________________ >> Postgres-xc-developers mailing list >> Pos...@li... >> https://lists.sourceforge.net/lists/listinfo/postgres-xc-developers >> >> > > > -- > Pavan Deolasee > http://www.linkedin.com/in/pavandeolasee > |