From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> |
Cc: | Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: How to share the result data of separated plan |
Date: | 2010-11-08 16:45:53 |
Message-ID: | 25961.1289234753@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com> writes:
> But reading closer your response, it occurred to me that ModifyTable
> can be the storage to be shared among separated plans instead of newly
> invented DtScan. Are you suggesting embed ModifyTable into the main
> query, that is also on the top of child plans? In this way we can
> still separate plans and scan the result of child plans without much
> modification of portal/explain?
There is noplace where we need to "scan the result of child plans".
We need to scan the set of RETURNING tuples emitted by a child
ModifyTable node. That has nothing whatever to do with what it wrote to
disk. We would hardly wish to try to reconstruct those tuples from
re-reading what it wrote to disk anyway --- that idea fails completely
for a DELETE RETURNING subquery, for example.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-08 17:00:42 | Re: Protecting against unexpected zero-pages: proposal |
Previous Message | Tom Lane | 2010-11-08 16:38:25 | Re: How to share the result data of separated plan |