On Wed, May 27, 2009 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not too thrilled about that solution because it still eliminates
predictability of execution of volatile functions.
How so? It means the volatile function might only be executed for the
matching rows but the rows will
Greg Stark wrote:
On Wed, May 27, 2009 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not too thrilled about that solution because it still eliminates
predictability of execution of volatile functions.
How so? It means the volatile function might only be executed for the
matching rows
Greg Stark st...@enterprisedb.com writes:
On Wed, May 27, 2009 at 12:47 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm not too thrilled about that solution because it still eliminates
predictability of execution of volatile functions.
How so? It means the volatile function might only be executed
Greg Stark st...@enterprisedb.com writes:
[ point 1 here remains unresolved:
http://archives.postgresql.org/message-id/9623.1223158...@sss.pgh.pa.us ]
One possibility would be to not flatten the query but find these quals
and copy them onto the cte when planning the cte. So we would still
2009/5/27 Tom Lane t...@sss.pgh.pa.us:
Greg Stark st...@enterprisedb.com writes:
[ point 1 here remains unresolved:
http://archives.postgresql.org/message-id/9623.1223158...@sss.pgh.pa.us ]
One possibility would be to not flatten the query but find these quals
and copy them onto the cte
Hitoshi Harada umi.tan...@gmail.com writes:
2009/5/27 Tom Lane t...@sss.pgh.pa.us:
I could still see doing what I mentioned in the prior message, which is
to flatten CTEs as if they are plain sub-selects when
1. they are non-recursive,
2. they are referenced only once, and
3. they contain
(quoting more than usual to provide context because this is such an old thread)
On Sat, Oct 4, 2008 at 11:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I've applied the latest version of the CTE patch. Congratulations on
making that happen!
There are still some loose ends that need to be
Bruce Momjian br...@momjian.us writes:
Is this a TODO?
I'm inclined to leave it as-is, at least till we get some field
feedback about how people want it to behave.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Is this a TODO?
---
Tom Lane wrote:
[ back to the when-to-inline-WITHs discussion ]
Gregory Stark st...@enterprisedb.com writes:
Tom Lane wrote:
Any thoughts on what to do? One possibility is to flatten only
if
On Oct 5, 2008, at 1:11 AM, Peter Eisentraut wrote:
I don't think we should overload syntax choices with optimization
hints. We don't really know why or how people will be using this
syntax, and labeling it from the start as will have unusual
performance behavior isn't a good sell.
As a
Agreed. It's already horrible that we suggest people use OFFSET 0, only
because we don't want to define formal optimizer hints (and that's *exactly*
what OFFSET 0 is).
Yes, especially since TFM says:
OFFSET 0 is the same as omitting the OFFSET clause.
Unless I'm looking at the wrong part of
[ back to the when-to-inline-WITHs discussion ]
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane wrote:
Any thoughts on what to do? One possibility is to flatten only
if the subquery doesn't contain any volatile functions.
I think we should always inline the view if there's a single call
If the planner chooses to do this as a nestloop with table2 on the
inside, then expensive_function() can get evaluated multiple times on
the same row of table2. We really don't make very many guarantees about
what will happen with functions inside inlined views, even with offset
0 as an
Tom Lane wrote:
that Oracle chooses to treat WITH-queries as if they were plain
sub-selects if they're non-recursive and only referenced once.
That is, Oracle would rewrite the above into
SELECT * FROM ( SELECT * FROM foo ) AS q WHERE key = 42;
and then flatten the sub-select and
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
2. The patch didn't touch the implicit-RTE code, which means that
WITH q AS ( SELECT ... )
SELECT q.*
will fail even if you've got add_missing_from enabled. I'm inclined
to think that this violates the principle of
Tom Lane wrote:
that Oracle chooses to treat WITH-queries as if they were plain
sub-selects if they're non-recursive and only referenced once.
That is, Oracle would rewrite the above into
SELECT * FROM ( SELECT * FROM foo ) AS q WHERE key = 42;
and then flatten the sub-select and
Gregory Stark [EMAIL PROTECTED] writes:
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
2. The patch didn't touch the implicit-RTE code, which means that
WITH q AS ( SELECT ... )
SELECT q.*
will fail even if you've got add_missing_from enabled.
Yes, it's legacy. I wouldn't
Hi all,
While i'm testing the HEAD version of CVS with this new feature, i
found a possible bug and like that more persons could try it in you
own box.
The attached file is a log of my test and I'm using a unprivileged
user to do it.
Thanks.
--
[]s
Dickson S. Guedes
Dickson S. Guedes [EMAIL PROTECTED] writes:
While i'm testing the HEAD version of CVS with this new feature, i
found a possible bug and like that more persons could try it in you
own box.
Yeah, that's a bug (two different ones in fact). Fixed --- thanks for
the report!
I've applied the latest version of the CTE patch. Congratulations on
making that happen!
There are still some loose ends that need to be considered, though.
1. As committed, the patch takes an extremely hard line about WITH
queries being evaluated independently of the main query and only once
On Sat, Oct 4, 2008 at 5:22 PM, Tom Lane [EMAIL PROTECTED] wrote:
that Oracle chooses to treat WITH-queries as if they were plain
sub-selects if they're non-recursive and only referenced once.
That is, Oracle would rewrite the above into
SELECT * FROM ( SELECT * FROM foo ) AS q WHERE
I've applied the latest version of the CTE patch. Congratulations on
making that happen!
Great! and thanks, Tom. Without your great help, we cannot make it
reality. I also would like to thank to everyone who helped this
project!
There are still some loose ends that need to be considered,
Tom Lane wrote:
I've applied the latest version of the CTE patch. Congratulations on
making that happen!
This is great news. A big thanks to all the people involved in making
this happen.
I've had several people come up to me during the conference that I've
been at that just ended asking if I
23 matches
Mail list logo
