Skip site navigation (1) Skip section navigation (2)

Re: CTE optimization fence on the todo list?

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Daniel Browning <db(at)kavod(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: CTE optimization fence on the todo list?
Date: 2012-10-01 14:49:29
Message-ID: 20121001144929.GB30089@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Oct  1, 2012 at 10:07:01AM -0400, Tom Lane wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> > I'm wondering if there are any technical/standards constraints that
> > are behind the fencing behavior.
> 
> I think the key reason is that we don't want partial execution of DML
> operations (ie, INSERT/UPDATE/DELETE inside a WITH).  The fencing
> behavior was put in originally because we foresaw adding DML later.
> 
> We could possibly relax the rule for WITH SELECT only, but it would
> be rather inconsistent, not to mention unpleasant for all the people
> who are relying on the current behavior for one reason or another.
> 
> Another issue is that if the CTE is scanned multiple times by the outer
> query, you really can't optimize it on the basis of any one call site.

If we wanted to relax the fencing, we might need to do it via an SQL
keyword on the SELECT, to avoid the confusion caused by GUCs.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-10-01 15:00:35
Subject: Re: pg_malloc() versus malloc(0)
Previous:From: Tom LaneDate: 2012-10-01 14:45:38
Subject: Re: pg_malloc() versus malloc(0)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group