Re: How to share the result data of separated plan

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How to share the result data of separated plan
Date: 2010-11-08 18:30:58
Message-ID: 27265.1289241058@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi> writes:
> On 2010-11-08 7:26 PM +0200, Tom Lane wrote:
>> The alternative is to artificially serialize the DML CTEs, which
>> while it does have some advantages doesn't seem like a win overall.

> We've discussed this before and the consensus was that as long as we
> don't change the results, we can optimize the materialization away.

No, because the problem is mainly about what might happen if
user-defined functions choose to look at the target tables. We can't
really tell what triggers are going to do, to take one item that the
planner has no access to.

I think we have to decide up front which implementation behavior
it's going to be, and if we go with serialized queries, we'll be
stuck with that.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Charles Pritchard 2010-11-08 18:36:16 Re: W3C Specs: Web SQL
Previous Message Pavel Stehule 2010-11-08 18:24:14 proposal: plpgsql - iteration over fields of rec or row variable