Tom Lane escribió:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Now there *is* one rather big performance problem in this patch, which
> > is that it turns on collection of object dropped data regardless of
> > there being event triggers that use the info at all. That's a serious
> > drawback and we're going to get complaints about it. So we need to do
> > something to fix that.
>
> > One idea that comes to mind is to add some more things to the grammar,
> > CREATE EVENT TRIGGER name ... WITH ('DROPPED OBJECTS');
>
> Uh ... surely we can just notice whether there's a trigger on the
> object-drop event? I don't understand why we need *yet more*
> mechanism here.
There's no object-drop event, only ddl_command_end. From previous
discussion I understood we didn't want a separate event, so that's what
we've been running with.
However, I think previous discussions have conflated many different
things, and we've been slowly fixing them one by one; so perhaps at this
point it does make sense to have a new object-drop event. Let's discuss
it -- we would define it as taking place just before ddl_command_end,
and firing any time a command (with matching tag?) has called
performDeletion or performMultipleDeletions. Does that sound okay?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
