| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Darren Duncan <darren(at)darrenduncan(dot)net> |
| Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: feature proposal - triggers by semantics |
| Date: | 2012-11-15 10:04:44 |
| Message-ID: | CAB7nPqSf-tybcYEoukUPaY9SNaRnqMtxVucRDGEoLQVBOivFjQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
A row-level trigger for TRUNCATE does not really make sense, as it would
mean that TRUNCATE needs to scan each tuple of the table it needs to
interact with to fire its trigger, so it would more or less achieve the
same performance as a plain "DELETE FROM table;".
TRUNCATE is performant because it only removes the tuples, and does not
care about scanning. I am also not sure it is meant for scanning (btw there
are discussions about TRUNCATE these days so I might be missing something).
So, what you are looking for can be simply solved with row-level triggers
on DELETE, so why not using that and avoid reinventing the wheel?
--
Michael Paquier
http://michael.otacoo.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2012-11-15 10:25:06 | Re: feature proposal - triggers by semantics |
| Previous Message | Magnus Hagander | 2012-11-15 10:04:25 | Re: Doc patch making firm recommendation for setting the value of commit_delay |