Re: Patch: plan invalidation vs stored procedures
От | Hannu Krosing |
---|---|
Тема | Re: Patch: plan invalidation vs stored procedures |
Дата | |
Msg-id | 1219224485.7109.70.camel@huvostro обсуждение исходный текст |
Ответ на | Re: Patch: plan invalidation vs stored procedures (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Tue, 2008-08-19 at 19:45 -0400, Tom Lane wrote: > Hannu Krosing <hannu@2ndQuadrant.com> writes: > > If there is plan invalidation then you just change called1() to return > > one more field and that's it - no juggling with C) and D) and generally > > less things that can go wrong. > > That is a pure flight of fancy. Nope, this is description of real situation when you have to maintain lots and lots of functions. > Adjusting a function's API generally > requires source-code changes on the caller side too. Adding a column to table does not (even generally) require changing all queries accessing that table, why should adding a column to functions return type do ? > There might be > a few limited cases where you can avoid that, but that doesn't leave > you with much of an argument that this is a critical bug fix. It's > a corner case and little more. It is a corner case if you don't have a dynamic system, evolving over time, which relies heavily on functions . It is a complete non-issue if you don't use functions at all. > FWIW, given that there will probably always be corner cases. I can see > the attraction in Simon's suggestion of providing a way to manually > issue a system-wide forced plan flush. That was also what I suggested as one blanket way of solving the bigger issue you brought up, that of not knowing where to stop tracking dependencies for plan invalidation. My thinking was, that this trades one-time inefficiency (replanning all stored plans) against more general but spread in time inefficiency of current patch (sending registration messages around for each function OID you depend on at each time you plan ). ------------ Hannu
В списке pgsql-hackers по дате отправления: