Ühel kenal päeval, T, 2007-03-20 kell 09:35, kirjutas Andrew Dunstan: > Florian G. Pflug wrote: > >> Are we really sure that this isn't a solution in search of a problem? > > I think this really depends on how you define "problem". Some people > > might think that "select * from myfunc(...) limit 1" should stop and > > return a result after myfunc(...) has returned one row. Others will > > say "well, just use a different software design that doesn't depend > > on this optimization".
The same argument could be used for justifying leaving out any optimisations. > I think that's a very thin use case to justify all the scaffolding you > propose, so put me in with the others I guess. > > If we can provide a per-call mechanism for C functions, that should be > adequate, I think. Sure, having it at least at C level would make the job of pl implementors wanting to do per-call returns a little easier. > If you need heavy optimization then you need C > functions anyway. Check out pl/proxy ( http://pgfoundry.org/projects/plproxy ), which is a dblink replacement and database partitioning tool in one. A short summary is here https://developer.skype.com/SkypeGarage/DbProjects/PlProxy (may be a bit outdated). I'm sure there would be use-cases (like moving huge tables) where per-call (or per-kilocall :) ) mechanisms would come handy. One example would be doing a huge sort split between N partitions so that each partition sorts its part of the data and then merge the results in-order from all partitions in-line, without doing re-sorting on the master. With a function returning the full recordset the sorting can't be distributed very effectively, as the whole query result needs to be saved on the master node before returning. -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
