Re: PL/R etc.

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: PL/R etc.
Дата
Msg-id CAHyXU0w3g_LG21oJhy9kD-yx1Y+G0-mybBdDk95jd_W+OaNWwQ@mail.gmail.com
обсуждение исходный текст
Ответ на PL/R etc.  (Mark Morgan Lloyd <markMLl.pgsql-general@telemetry.co.uk>)
Ответы Re: PL/R etc.  (Joe Conway <mail@joeconway.com>)
Список pgsql-general
On Fri, May 10, 2013 at 4:41 AM, Mark Morgan Lloyd
<markMLl.pgsql-general@telemetry.co.uk> wrote:
> I don't know whether anybody active on the list has R (and in particular
> PL/R) experience, but just in case... :-)
>
> i)   Something like APL can operate on an array with minimal regard for
> index order, i.e. operations across the array are as easily-expressed and as
> efficient as operations down the array. Does this apply to PL/R?
>
> ii)  Things like OpenOffice can be very inefficient if operating over a
> table comprising a non-trivial number of rows. Does PL/R offer a significant
> improvement, e.g. by using a cursor rather than trying to read an entire
> resultset into memory?

pl/r (via R) very terse and expressive.  it will probably meet or beat
any performance expectations you have coming from openoffice.   that
said, it's definitely a memory bound language; typically problem
solving involves stuffing data into huge data frames which then pass
to the high level problem solving functions like glm.

you have full access to sql within the pl/r function, so nothing is
keeping you from paging data into the frame via a cursor, but that
only helps so much.

a lot depends on the specific problem you solve of course.

merlin


В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: FATAL: database "a/system_data" does not exist
Следующее
От: Carlos Henrique Reimer
Дата:
Сообщение: PG in cash till machines