Re: Writeable CTEs and side effects
От | Marko Tiikkaja |
---|---|
Тема | Re: Writeable CTEs and side effects |
Дата | |
Msg-id | 4ACDC6D1.7000703@cs.helsinki.fi обсуждение исходный текст |
Ответ на | Re: Writeable CTEs and side effects (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Writeable CTEs and side effects
|
Список | 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 по дате отправления: