Re: BUG #5982: recursive type crashes postgres - Mailing list pgsql-bugs

From Andrew Chernow
Subject Re: BUG #5982: recursive type crashes postgres
Date
Msg-id 4DA8D48B.2050404@esilo.com
Whole thread Raw
In response to Re: BUG #5982: recursive type crashes postgres  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
List pgsql-bugs
On 4/15/2011 6:14 PM, Kevin Grittner wrote:
> Merlin Moncure<mmoncure@gmail.com>  wrote:
>
>> Consider we also have to send data to the database.  I can
>> recursively wrap up data in the client using libpqtypes, fire it
>> to a receiving function which unnests it and processes it.  This
>> is a couple of orders of magnitude faster than streaming it in
>> over multiple queries.
>
> I'll think on that.  I hadn't really considered creating an ORM in
> the database engine itself, which seems to me to be what you're
> describing, but I guess it couldn't be worse than having an ORM on
> the other end of the wire.
>
> Is that a hard sell to your application programmers, or do you wear
> both hats?
>

libpqtypes is very easy to use, small learning curve.  Should be easy for
someone with libpq experience.

Merlin is describing loop,pack,exec vs. loop,exec where the former packs an
array of parameters and performs one transaction, and the latter must execute
multiple transactions one at a time.  If you take the params of an insert and
create a composite out of it, you can wrap the insert into a function that takes
an array of that composite.  You are not creating any new bindings, translations
or encodings, just leveraging existing functionality a little differently.

--
Andrew Chernow
eSilo, LLC
global backup
http://www.esilo.com/

pgsql-bugs by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: BUG #5982: recursive type crashes postgres
Next
From: Mark Kirkwood
Date:
Subject: Re: Massive memory use for star query