Hi, Tom,
Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>> The specific concern I have is large result sets, like 10s or 100s of MB
>> (or more). We just added support for not buffering those in psql, so it
>> seems like a step backwards to have the backend now buffering it (unless
>
I wrote:
> ISTM that ideally, a query with RETURNING ought to act like a SELECT
> for the purposes of a SQL function --- to wit, that the result rows are
> discarded if it's not the last query in the function, and are returned
> as the function result if it is.
The current state of affairs is that
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Sure, it's just a lot of data to be shuffling around if we can avoid it.
> Perhaps we could only do this if there's triggers on the table involved?
Maybe, but it's awfully late in the 8.2 cycle to be worrying about
performance improvements for something
On Thu, Oct 12, 2006 at 03:03:43PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > The specific concern I have is large result sets, like 10s or 100s of MB
> > (or more). We just added support for not buffering those in psql, so it
> > seems like a step backwards to have the
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> The specific concern I have is large result sets, like 10s or 100s of MB
> (or more). We just added support for not buffering those in psql, so it
> seems like a step backwards to have the backend now buffering it (unless
> I'm confused on how a tuplesto
David Fetter <[EMAIL PROTECTED]> writes:
> More generally, would this change impede promoting RETURNING to work
> just as VALUES does in 8.2 (i.e. being able to join RETURNING results,
> etc.)?
Making that happen would imply a whole lot of other changes; this issue
isn't the principal gating facto
On Thu, Oct 12, 2006 at 02:50:34PM -0400, Tom Lane wrote:
> > ISTM that pushing to a tuplestore is a lot of extra work for
>
> I'm not entirely convinced of that --- the overhead of getting down
> through functions.c and ExecutorRun into the per-tuple loop isn't
> trivial either. It wouldn't work
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Thu, Oct 12, 2006 at 12:19:24PM -0400, Tom Lane wrote:
>> I think the most promising answer may be to push RETURNING rows into a
>> TupleStore and then read them out from there, which is pretty much the
>> same approach we adopted for RETURNING querie
On Thu, Oct 12, 2006 at 01:28:18PM -0500, Jim C. Nasby wrote:
> On Thu, Oct 12, 2006 at 12:19:24PM -0400, Tom Lane wrote:
> > I think the most promising answer may be to push RETURNING rows
> > into a TupleStore and then read them out from there, which is
> > pretty much the same approach we adopte
On 10/12/06, Tom Lane <[EMAIL PROTECTED]> wrote:
I think the most promising answer may be to push RETURNING rows into a
TupleStore and then read them out from there, which is pretty much the
same approach we adopted for RETURNING queries inside portals.
It certainly sounds like the safest imple
On Thu, Oct 12, 2006 at 12:19:24PM -0400, Tom Lane wrote:
> I think the most promising answer may be to push RETURNING rows into a
> TupleStore and then read them out from there, which is pretty much the
> same approach we adopted for RETURNING queries inside portals. This'd
> allow the query to b
11 matches
Mail list logo
