Re: Add on_perl_init and proper destruction to plperl [PATCH]
От | Tim Bunce |
---|---|
Тема | Re: Add on_perl_init and proper destruction to plperl [PATCH] |
Дата | |
Msg-id | 20100127212741.GI713@timac.local обсуждение исходный текст |
Ответ на | Re: Add on_perl_init and proper destruction to plperl [PATCH] (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Add on_perl_init and proper destruction to plperl [PATCH]
|
Список | pgsql-hackers |
On Wed, Jan 27, 2010 at 11:28:02AM -0500, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > > Tom Lane wrote: > >> Indeed, AFAICS the major *point* of these additions is to allow people > >> to insert unknown other functionality that is likely to interact > >> with the rest of the backend; a prospect that doesn't make me feel > >> better about it. > > > No. The major use case we've seen for END blocks is to allow a profiler > > to write its data out. That should have zero interaction with the rest > > of the backend. > > Really? We've found that gprof, for instance, doesn't exactly have > "zero interaction with the rest of the backend" --- there's actually > a couple of different bits in there to help it along, including a > behavioral change during shutdown. I rather doubt that Perl profilers > would turn out much different. Devel::NYTProf (http://blog.timbunce.org/tag/nytprof/) has zero interaction with the rest of the backend. It works in PostgreSQL 8.4, although greatly handicapped by the lack of END blocks. http://search.cpan.org/perldoc?Devel::NYTProf::PgPLPerl > But in any case, I don't believe for a moment that profiling is the only > or even the largest use to which people would try to put this. Can you give any examples? Tim.
В списке pgsql-hackers по дате отправления: