| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
| Cc: | Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Status report on writeable CTEs |
| Date: | 2010-07-21 00:34:08 |
| Message-ID: | AANLkTimhbOC0j1TNoQaykiTs2Jy+iLQ2GSwVL4ejwzny@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 20, 2010 at 5:13 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>>> 2. Use temp table instead of tuplestore list. Since we agreed we need
>>>> to execute each plan one by one starting and shutting down executor,
>>>> it now looks very simple strategy.
>>>
>>> I didn't look at this because I thought using a "tuplestore receiver" in the
>>> portal logic was simple enough. Any thoughts on how this would work?
>>
>> It's just deconstructing queries like:
>>
>> WITH t AS (INSERT INTO x ... RETURING *)
>> SELECT * FROM t;
>>
>> to
>>
>> CREATE TEMP TABLE t AS INSERT INTO x ... RETURING *;
>> SELECT * FROM t;
>
> Is it acceptable for a wCTE query to manipulate the system catalogs?
> Couldn't this cause performance issues in some cases?
Yeah, I suspect the performance wouldn't be too hot. I think the idea
of writing into a tuplestore and then reading back out from it is the
way to go.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-07-21 00:36:47 | Re: Finding slave WAL application time delay |
| Previous Message | Andrew Dunstan | 2010-07-21 00:28:57 | Re: antisocial things you can do in git (but not CVS) |