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: | Raw Message | Whole Thread | 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) |