Greg Stark writes:
> On Wed, May 27, 2009 at 12:47 AM, Tom Lane 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
Exactly.
Greg Stark wrote:
On Wed, May 27, 2009 at 12:47 AM, Tom Lane 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 sti
On Wed, May 27, 2009 at 12:47 AM, Tom Lane 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 still have the same v
Hitoshi Harada writes:
> 2009/5/27 Tom Lane :
>> 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 no volatile functions.
>
2009/5/27 Tom Lane :
> Greg Stark 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 woul
Greg Stark 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
> materialize the re
(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 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 considered, though.
>
Is this a TODO?
---
Tom Lane wrote:
> [ back to the when-to-inline-WITHs discussion ]
>
> Gregory Stark writes:
> >> Tom Lane wrote:
> >>> Any thoughts on what to do? One possibility is to flatten only
> >>> if the subque
Bruce Momjian 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 to your subscript
> 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 a
[ 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 sing
> 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
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
"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!
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
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.
>>
>> Y
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
> 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-
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 optimi
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'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, t
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
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
pe
23 matches
Mail list logo
