Ü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
