On Fri, May 1, 2015 at 2:39 PM, Tom Lane t...@sss.pgh.pa.us 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
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 jim.na...@bluetreble.com wrote:
On 5/3/15 11:59 AM, Andrew Dunstan wrote:
On
On 5/3/15 11:59 AM, Andrew Dunstan wrote:
On 05/03/2015 11:49 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Andrew Dunstan and...@dunslane.net 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
On 05/03/2015 11:49 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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,
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
On Fri, May 1, 2015 at 3:30 PM, Tom Lane t...@sss.pgh.pa.us 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
David Steele da...@pgmasters.net 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 ---
On Fri, May 1, 2015 at 3:30 PM, Tom Lane t...@sss.pgh.pa.us 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
On 5/1/15 6:32 PM, Peter Geoghegan wrote:
On Fri, May 1, 2015 at 3:30 PM, Tom Lane t...@sss.pgh.pa.us 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
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 it
On Fri, May 1, 2015 at 4:53 PM, Jim Nasby jim.na...@bluetreble.com 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
On 4/30/15 6:35 AM, Robert Haas wrote:
On Thu, Apr 30, 2015 at 12:44 AM, Chris Rogers teuk...@gmail.com 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.
Jim Nasby jim.na...@bluetreble.com writes:
On 4/30/15 6:35 AM, Robert Haas wrote:
On Thu, Apr 30, 2015 at 12:44 AM, Chris Rogers teuk...@gmail.com 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
On Fri, May 1, 2015 at 2:36 PM, Robert Haas robertmh...@gmail.com wrote:
On Fri, May 1, 2015 at 4:53 PM, Jim Nasby jim.na...@bluetreble.com 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
On 5/1/15 5:39 PM, Tom Lane wrote:
Jim Nasby jim.na...@bluetreble.com writes:
On 4/30/15 6:35 AM, Robert Haas wrote:
On Thu, Apr 30, 2015 at 12:44 AM, Chris Rogers teuk...@gmail.com wrote:
I could really use the ability to optimize across CTE boundaries, and it
seems like a lot of other
On Thu, Apr 30, 2015 at 12:44 AM, Chris Rogers teuk...@gmail.com 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
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.
On Wed, Sep 19, 2012 at 3:05 PM, Daniel Browning d...@kavod.com 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
On 1 October 2012 14:05, Merlin Moncure mmonc...@gmail.com wrote:
On Wed, Sep 19, 2012 at 3:05 PM, Daniel Browning d...@kavod.com 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
Merlin Moncure mmonc...@gmail.com 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
Merlin Moncure mmonc...@gmail.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
On Mon, Oct 1, 2012 at 10:07:01AM -0400, Tom Lane wrote:
Merlin Moncure mmonc...@gmail.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,
* 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
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
25 matches
Mail list logo
