Re: Writeable CTEs and side effects - Mailing list pgsql-hackers

From Marko Tiikkaja
Subject Re: Writeable CTEs and side effects
Date
Msg-id 4ACDC6D1.7000703@cs.helsinki.fi
Whole thread Raw
In response to Re: Writeable CTEs and side effects  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Writeable CTEs and side effects
List pgsql-hackers
Robert Haas wrote:
> This has one MAJOR disadvantage: all the tuples from the CTE queries
> have to be buffered someplace, rather than streamed from the subquery
> up to the main query.  For what may turn out to be pretty common uses
> cases like WITH tuples AS (DELETE FROM big_table_1 RETURNING ...)
> INSERT INTO big_table_2 ... this is going to suck pretty bad.  I
> wonder if it isn't better to just use the same command-ID throughout
> and live with the weirdness of #2.

I haven't looked at the CTE code in much detail but I was under the
impression that it had to store the results somewhere in any case.
You're right, though, it sucks for this use case.  Weirdness of #2 is
probably a lot easier to live with.

> I think you should definitely get some input from Tom Lane on this
> before you go too much further, but if he doesn't respond to this
> thread, I suggest trying again after CommitFest.

Agreed.

> Does this have any impact on the pending DML-node patch?

Not really.  This could be done without the patch, but we can use far
more of the existing CTE code with the patch.


Regards,
Marko Tiikkaja



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Writeable CTEs and side effects
Next
From: Chris Browne
Date:
Subject: Re: Rules: A Modest Proposal