On Fri, May 1, 2015 at 2:39 PM, Tom Lane wrote:
> * Multiply-referenced WITH item (unless the outer query applies
> identical constraints to each reference, which seems silly and not
> worth the cycles to check for).
>
Not sure if I understand this correctly. Look at this query, CTE q is
reference
On Wed, May 20, 2015 at 12:58 AM, Chris Rogers wrote:
> I need this feature a lot. Can anyone point me to a place in the code where
> I can hack together a quick-and-dirty, compatibility-breaking
> implementation? Thanks!
Does this help?
http://www.postgresql.org/message-id/38448.1430519...@ss
I need this feature a lot. Can anyone point me to a place in the code
where I can hack together a quick-and-dirty, compatibility-breaking
implementation? Thanks!
On Sun, May 3, 2015 at 10:03 PM, Jim Nasby wrote:
> On 5/3/15 11:59 AM, Andrew Dunstan wrote:
>
>>
>> On 05/03/2015 11:49 AM, Tom La
On 5/3/15 11:59 AM, Andrew Dunstan wrote:
On 05/03/2015 11:49 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 05/01/2015 07:24 PM, Josh Berkus wrote:
(A possible compromise position would be to offer a new GUC to
enable/disable the optimization globally; that would add only a
reasonably
small
On 05/03/2015 11:49 AM, Tom Lane wrote:
Andrew Dunstan writes:
On 05/01/2015 07:24 PM, Josh Berkus wrote:
(A possible compromise position would be to offer a new GUC to
enable/disable the optimization globally; that would add only a reasonably
small amount of control code, and people who were
Andrew Dunstan writes:
> On 05/01/2015 07:24 PM, Josh Berkus wrote:
>>> (A possible compromise position would be to offer a new GUC to
>>> enable/disable the optimization globally; that would add only a reasonably
>>> small amount of control code, and people who were afraid of the change
>>> break
On 05/01/2015 07:24 PM, Josh Berkus wrote:
O
(A possible compromise position would be to offer a new GUC to
enable/disable the optimization globally; that would add only a reasonably
small amount of control code, and people who were afraid of the change
breaking their apps would probably want a
On Fri, May 1, 2015 at 3:30 PM, Tom Lane wrote:
> Assuming that that sketch is accurate, it would take more code to provide
> a new user-visible knob to enable/disable the behavior than it would to
> implement the optimization, which makes me pretty much -1 on providing
> such a knob. We should
On 05/01/2015 03:30 PM, Tom Lane wrote:
> Assuming that that sketch is accurate, it would take more code to provide
> a new user-visible knob to enable/disable the behavior than it would to
> implement the optimization, which makes me pretty much -1 on providing
> such a knob. We should either do
On 5/1/15 6:32 PM, Peter Geoghegan wrote:
> On Fri, May 1, 2015 at 3:30 PM, Tom Lane wrote:
>> Assuming that that sketch is accurate, it would take more code to provide
>> a new user-visible knob to enable/disable the behavior than it would to
>> implement the optimization, which makes me pretty m
On Fri, May 1, 2015 at 3:30 PM, Tom Lane wrote:
> Assuming that that sketch is accurate, it would take more code to provide
> a new user-visible knob to enable/disable the behavior than it would to
> implement the optimization, which makes me pretty much -1 on providing
> such a knob. We should e
David Steele writes:
> On 5/1/15 5:39 PM, Tom Lane wrote:
>> I doubt that the spec says anything about it one way or another.
>> However, there are a lot of cases where we definitely can't push
>> constraints into a WITH:
>> * Data-modifying query in the WITH, eg UPDATE RETURNING --- pushing
>> ou
On 5/1/15 5:39 PM, Tom Lane wrote:
> Jim Nasby writes:
>> On 4/30/15 6:35 AM, Robert Haas wrote:
>>> On Thu, Apr 30, 2015 at 12:44 AM, Chris Rogers wrote:
I could really use the ability to optimize across CTE boundaries, and it
seems like a lot of other people could too.
>
>>> I'm not
On Fri, May 1, 2015 at 2:36 PM, Robert Haas wrote:
> On Fri, May 1, 2015 at 4:53 PM, Jim Nasby wrote:
>> ISTR a comment to the effect of the SQL standard effectively requires
>> current behavior.
>
> I'd be astonished. The SQL standard doesn't even know that there is
> such a thing as an index,
Jim Nasby writes:
> On 4/30/15 6:35 AM, Robert Haas wrote:
>> On Thu, Apr 30, 2015 at 12:44 AM, Chris Rogers wrote:
>>> I could really use the ability to optimize across CTE boundaries, and it
>>> seems like a lot of other people could too.
>> I'm not aware that anyone is working on it.
> ISTR
On Fri, May 1, 2015 at 4:53 PM, Jim Nasby wrote:
> ISTR a comment to the effect of the SQL standard effectively requires
> current behavior.
I'd be astonished. The SQL standard doesn't even know that there is
such a thing as an index, so I presume it doesn't dictate the behavior
of the query pla
On 4/30/15 6:35 AM, Robert Haas wrote:
On Thu, Apr 30, 2015 at 12:44 AM, Chris Rogers wrote:
Has there been any movement on this in the last couple years?
I could really use the ability to optimize across CTE boundaries, and it
seems like a lot of other people could too.
I'm not aware that a
On Thu, Apr 30, 2015 at 12:44 AM, Chris Rogers wrote:
> Has there been any movement on this in the last couple years?
>
> I could really use the ability to optimize across CTE boundaries, and it
> seems like a lot of other people could too.
I'm not aware that anyone is working on it.
--
Robert
Has there been any movement on this in the last couple years?
I could really use the ability to optimize across CTE boundaries, and it
seems like a lot of other people could too.
* Bruce Momjian (br...@momjian.us) wrote:
> 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.
I like the idea of providing a way for users to request non-fencing,
perhaps only allowed for SELECT CTEs. I don't like
On Mon, Oct 1, 2012 at 10:07:01AM -0400, Tom Lane wrote:
> Merlin Moncure 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
Merlin Moncure 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 be
Merlin Moncure writes:
> I'm wondering if there are any technical/standards constraints that
> are behind the fencing behavior. If there aren't any, maybe an opt-in
The fencing is per standard, and very useful when used in wCTEs.
> keyword might do the trick -- WITH UNBOXED foo AS (..)?
I woul
On 1 October 2012 14:05, Merlin Moncure wrote:
> On Wed, Sep 19, 2012 at 3:05 PM, Daniel Browning wrote:
> I'm wondering if there are any technical/standards constraints that
> are behind the fencing behavior. If there aren't any, maybe an opt-in
> keyword might do the trick -- WITH UNBOXED foo
On Wed, Sep 19, 2012 at 3:05 PM, Daniel Browning wrote:
> Another good reason to reject it might be because the only way to disable
> the CTE fence is to disable it by default. If that were the case, then I
> would imagine that it would break backwards compatibility, especially in the
> case of wr
I would like to have the option of disabling the CTE optimization fence for
certain CTEs and/or queries. Can that be added to the official todo list? If
not, why not?
I would find the option beneficial because large, complicated queries are
often a lot clearer, simpler, and easier to read with
26 matches
Mail list logo
