David Fetter [EMAIL PROTECTED] writes:
How hard would it be to add the infrastructure for CYCLE?
Personally I'm more interested in getting the recursive UNION (without
ALL) case to work.
I think that this might just be a matter of drawing on support that's
already there: have RecursiveUnion
On Fri, Oct 03, 2008 at 03:55:56PM -0400, Tom Lane wrote:
I've successfully taught the WITH patch to do single evaluation of
WITH queries. I've also been through all of the planner and
executor code for it and am now feeling pretty happy with the whole
thing. There are still a small number
On 2 Oct 2008, at 05:44 AM, Tom Lane [EMAIL PROTECTED] wrote:
Hitoshi Harada [EMAIL PROTECTED] writes:
Hmm, I've looked over the patch. Logically window functions can
access
arbitrary rows that have been stored in a frame. Thus I had thought
tuplestore should hold all the positions and
Hitoshi Harada [EMAIL PROTECTED] writes:
It seems to me to share some ideas with the MemoryContext concept: what
about a TupstoreContext associated with tuplestore, you get a common default
one if you don't register your own, and use
tuplestore_gettuple(MyTupstoreContext, ...);
I'm just
Greg Stark [EMAIL PROTECTED] writes:
On Wed, Oct 1, 2008 at 2:54 PM, Tom Lane [EMAIL PROTECTED] wrote:
So it seems like the appropriate generalization is to have an array of
read positions inside the tuplestore and allow callers to say read
using position N, plus some API to allow positions to
On Wed, Oct 1, 2008 at 2:54 PM, Tom Lane [EMAIL PROTECTED] wrote:
So it seems like the appropriate generalization is to have an array of
read positions inside the tuplestore and allow callers to say read
using position N, plus some API to allow positions to be allocated to
different
One other reason the tuplestore should know the position of all the
readers is that ideally it would want to be able to discard any tuples
older than the oldest read position. That also means it needs to know
when all the call sites have allocated their position and don't need
to reset it.
Hitoshi Harada [EMAIL PROTECTED] writes:
I hadn't realized that this would be relevant to window functions.
Now that I know that, I propose fixing tuplestore for multiple
positions and committing it separately, before I go back to the CTE
patch. Then Hitoshi-san will have something he can
2008/10/2 Tom Lane [EMAIL PROTECTED]:
Hitoshi Harada [EMAIL PROTECTED] writes:
I hadn't realized that this would be relevant to window functions.
Now that I know that, I propose fixing tuplestore for multiple
positions and committing it separately, before I go back to the CTE
patch. Then
Hitoshi Harada [EMAIL PROTECTED] writes:
2008/10/2 Tom Lane [EMAIL PROTECTED]:
Okay, there's a patch in CVS HEAD that works this way. Let me know if
it needs further tweaking for your purposes.
Hmm, I've looked over the patch. Logically window functions can access
arbitrary rows that have
Greg Stark [EMAIL PROTECTED] writes:
On 24 Sep 2008, at 02:45, Tom Lane [EMAIL PROTECTED] wrote:
The next big
thing seems to be to figure out exactly how to do multiple references
to CTE outputs, so that we can de-bogotify the planner.
I've looked and don't seem to still have the source tree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 30 sept. 08 à 20:03, Tom Lane a écrit :
set_read_position(tupstore, local_read_position);
tuple = tuplestore_gettuple(tupstore, ...);
get_read_position(tupstore, local_read_position);
rather than just
Hi,
2008/10/1 Dimitri Fontaine [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Le 30 sept. 08 à 20:03, Tom Lane a écrit :
set_read_position(tupstore, local_read_position);
tuple = tuplestore_gettuple(tupstore, ...);
get_read_position(tupstore,
greg
On 24 Sep 2008, at 02:45, Tom Lane [EMAIL PROTECTED] wrote:
The next big
thing seems to be to figure out exactly how to do multiple references
to CTE outputs, so that we can de-bogotify the planner.
I've looked and don't seem to still have the source tree where I
worked on this. I
Tom,
WithClause node may need a location field, and almost certainly has to
be handled somehow in exprLocation().
The error reports in parse_cte.c *desperately* need error locations.
Included is a patch for this against your cte-0923.patch.gz. Most
errors now have error locations, but
Jeff Davis [EMAIL PROTECTED] writes:
Here is a patch that is an initial attempt to reorganize the parse tree
representation.
Oh dear, we seem to have spent yesterday doing the same work :-(
I'll go over this and try to merge it with my own WIP.
* There are a couple of other rough points in
Tom Lane [EMAIL PROTECTED] writes:
Yeah, I'd been running into that issue too. Adding an explicit pointer
to the CTE into the RTE doesn't work because it renders the parse tree
un-copiable (at least without something a lot more sophisticated than
copyObject; and saving/loading rule
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Yeah, I'd been running into that issue too. Adding an explicit pointer
to the CTE into the RTE doesn't work because it renders the parse tree
un-copiable (at least without something a lot more sophisticated than
Attached is the result of a couple of days hacking on the WITH RECURSIVE
patch. This moves us a lot closer to having sanity in the parsing
phase, though I'm still quite unhappy with the second half of the
processing in parse_cte.c. I added some infrastructure to make the
first half's search for
I am re-sending this message to -hackers from yesterday, because the
first time it didn't appear to make it through. This time I gzipped the
patch. This is just for the archives (and to give context to the
replies), and this message is superseded by Tom's patch here:
PlanState.has_recursivescan seems like a complete kluge. Can't it just be
removed? It looks to me like it is working around bugs that hopefully aren't
there anymore. There is certainly no reason why a recursive CTE should be
more in need of rescanning than any other kind of plan.
I don't
Tatsuo Ishii [EMAIL PROTECTED] writes:
PlanState.has_recursivescan seems like a complete kluge. Can't it just be
removed? It looks to me like it is working around bugs that hopefully aren't
there anymore. There is certainly no reason why a recursive CTE should be
more in need of rescanning
Why does set_recursion_pathlist think that the subquery might have
useful pathkeys? We know it must always be a UNION ALL, no?
Right. But someday we might implement UNION (without ALL) then we
have useful pathkeys...
Or shall I completely remove the step to generate patheys and do not
pass
Tatsuo Ishii [EMAIL PROTECTED] writes:
Why does set_recursion_pathlist think that the subquery might have
useful pathkeys? We know it must always be a UNION ALL, no?
Right. But someday we might implement UNION (without ALL) then we
have useful pathkeys...
Good point. Might as well leave it
2008/9/17 Tom Lane [EMAIL PROTECTED]:
Tatsuo Ishii [EMAIL PROTECTED] writes:
Do we really have to make RECURSIVE a fully reserved keyword?
According to the standard, RECURSIVE is a reserved keyword, I believe.
Sure, but our general rule is to make keywords no more reserved than
is
I am not sure, if these rule is good. Somebody who develop on
postgresql should have a problems when they will be port to other
databases in future. Reserved words in standards should be respected.
I disagree. I have never ported an app written for PostgreSQL to
another database system, and
Robert Haas [EMAIL PROTECTED] writes:
I am not sure, if these rule is good. Somebody who develop on
postgresql should have a problems when they will be port to other
databases in future. Reserved words in standards should be respected.
I disagree. I have never ported an app written for
Tom Lane [EMAIL PROTECTED] wrote:
Robert Haas [EMAIL PROTECTED] writes:
I am not sure, if these rule is good. Somebody who develop on
postgresql should have a problems when they will be port to other
databases in future. Reserved words in standards should be
respected.
If people want to
Is physical_tlist optimization sensible for RecursiveScan? We seem
to use it for every other Scan node type.
To enable physical_tlist optimization, it seems build_physical_tlist,
use_physical_tlist and disuse_physical_tlist need to be
changed. build_physical_tlist and use_physical_tlist have
Tatsuo Ishii [EMAIL PROTECTED] writes:
Is physical_tlist optimization sensible for RecursiveScan? We seem
to use it for every other Scan node type.
To enable physical_tlist optimization, it seems build_physical_tlist,
use_physical_tlist and disuse_physical_tlist need to be
changed.
To enable physical_tlist optimization, it seems build_physical_tlist,
use_physical_tlist and disuse_physical_tlist need to be
changed. build_physical_tlist and use_physical_tlist have been already
patched and only disuse_physical_tlist needs to be patched. Any other
place I miss to
Tom, thanks for the review.
Here is an in-progress report. Patches against CVS HEAD attached.
(uncommented items are work-in-progress).
--
Tatsuo Ishii
SRA OSS, Inc. Japan
Tatsuo Ishii [EMAIL PROTECTED] writes:
Included is the latest patches against CVS HEAD.
I spent some time reading this
On Mon, Sep 15, 2008 at 06:46:16PM +0900, Tatsuo Ishii wrote:
* Single Evaluation:
with
foo(i) as (select random() as i)
select * from foo union all select * from foo;
i
---
0.233165248762816
0.62126633618027
(2 rows)
On Mon, 2008-09-15 at 22:41 -0700, David Fetter wrote:
On Mon, Sep 15, 2008 at 06:46:16PM +0900, Tatsuo Ishii wrote:
* Single Evaluation:
with
foo(i) as (select random() as i)
select * from foo union all select * from foo;
i
---
Tatsuo Ishii [EMAIL PROTECTED] writes:
Included is the latest patches against CVS HEAD.
I spent some time reading this patch. Here are a few comments in
no particular order:
RangeRecursive node lacks copyfuncs/equalfuncs support.
Query.recursive is missed in equalfuncs.c. But rather than fix
Jeff Davis [EMAIL PROTECTED] writes:
I think the right approach is to try to complete it so that everyone is
happy. I will work on this, but unfortunately I don't have a lot of time
right now, so I can't make any promises.
I think there are two significant bits there:
* Fixing the parsetree
I had either on that a while back. I think the existing tuplestore can
be made to work without bad performance penaltiesbin the usual case.
The trick was to do it without making the code unreadable.
I can send the code I had but I doubt you want to use it as-is.
--
greg
--
Sent via
Greg Stark [EMAIL PROTECTED] writes:
I had either on that a while back. I think the existing tuplestore can
be made to work without bad performance penaltiesbin the usual case.
The trick was to do it without making the code unreadable.
I can send the code I had but I doubt you want to use
Do we really have to make RECURSIVE a fully reserved keyword?
According to the standard, RECURSIVE is a reserved keyword, I believe.
(Actually, the patch makes it worse than reserved, by failing to
add it to the reserved_keywords list.)
Yes, it's a bug. Will fix...
--
Tatsuo Ishii
SRA OSS,
Tatsuo Ishii [EMAIL PROTECTED] writes:
Do we really have to make RECURSIVE a fully reserved keyword?
According to the standard, RECURSIVE is a reserved keyword, I believe.
Sure, but our general rule is to make keywords no more reserved than
is absolutely necessary to make the bison grammar
* Single Evaluation:
with
foo(i) as (select random() as i)
select * from foo union all select * from foo;
i
---
0.233165248762816
0.62126633618027
(2 rows)
The standard specifies that non-recursive WITH should be evaluated
On Tue, 2008-09-09 at 09:47 -0400, Robert Haas wrote:
3. I think this is a must fix because of the point about volatile
functions --- changing it later will result in user-visible semantics
changes, so we have to get it right the first time.
I don't entirely agree with #3. It is
I meant that -- hypothetically if we did accept the feature as-is -- the
number of evaluations would be documented to be undefined, not N. That
would avoid the backwards-compatibility problem.
This one point is probably not worth discussing now, because argument
#1 and #2 stand on their own.
On Tue, 2008-09-09 at 13:45 +0900, Tatsuo Ishii wrote:
Thanks for the review.
The standard specifies that non-recursive WITH should be evaluated
once.
What shall we do? I don't think there's a easy way to fix this. Maybe
we should not allow WITH clause without RECURISVE?
My
3. I think this is a must fix because of the point about volatile
functions --- changing it later will result in user-visible semantics
changes, so we have to get it right the first time.
I don't entirely agree with #3. It is user-visible, but only in the
sense that someone is depending on
On Tue, 2008-09-09 at 13:45 +0900, Tatsuo Ishii wrote:
Thanks for the review.
The standard specifies that non-recursive WITH should be evaluated
once.
What shall we do? I don't think there's a easy way to fix this. Maybe
we should not allow WITH clause without RECURISVE?
Hello
2008/9/9 Tatsuo Ishii [EMAIL PROTECTED]:
On Tue, 2008-09-09 at 13:45 +0900, Tatsuo Ishii wrote:
Thanks for the review.
The standard specifies that non-recursive WITH should be evaluated
once.
What shall we do? I don't think there's a easy way to fix this. Maybe
we
Hello
2008/9/9 Tatsuo Ishii [EMAIL PROTECTED]:
On Tue, 2008-09-09 at 13:45 +0900, Tatsuo Ishii wrote:
Thanks for the review.
The standard specifies that non-recursive WITH should be evaluated
once.
What shall we do? I don't think there's a easy way to fix this. Maybe
Hello
2008/9/9 Tatsuo Ishii [EMAIL PROTECTED]:
On Tue, 2008-09-09 at 13:45 +0900, Tatsuo Ishii wrote:
Thanks for the review.
The standard specifies that non-recursive WITH should be evaluated
once.
What shall we do? I don't think there's a easy way to fix this. Maybe
* Aggregates allowed:
with recursive foo(i) as
(values(1)
union all
select max(i)+1 from foo where i 10)
select * from foo;
Aggregates should be blocked according to the standard.
Also, causes an infinite loop. This should be fixed for 8.4.
I will try
2008/9/9 Tatsuo Ishii [EMAIL PROTECTED]:
Hello
2008/9/9 Tatsuo Ishii [EMAIL PROTECTED]:
On Tue, 2008-09-09 at 13:45 +0900, Tatsuo Ishii wrote:
Thanks for the review.
The standard specifies that non-recursive WITH should be evaluated
once.
What shall we do? I don't
My interpretation of 7.13: General Rules: 2.b is that it should be
single evaluation, even if RECURSIVE is present.
The previous discussion was here:
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01292.php
I am blind, I didn't find any reason, why materialisation isn't
2008/9/9 Robert Haas [EMAIL PROTECTED]:
My interpretation of 7.13: General Rules: 2.b is that it should be
single evaluation, even if RECURSIVE is present.
The previous discussion was here:
http://archives.postgresql.org/pgsql-hackers/2008-07/msg01292.php
I am blind, I didn't find
On Tue, 2008-09-09 at 18:51 +0200, Pavel Stehule wrote:
hmm. I solve similar problem in grouping sets :( etc
How did you solve it?
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
2008/9/9 Jeff Davis [EMAIL PROTECTED]:
On Tue, 2008-09-09 at 18:51 +0200, Pavel Stehule wrote:
hmm. I solve similar problem in grouping sets :( etc
I have special executor node - feeder, it hold one tuple and others
nodes read from this node. It's usable for hash aggregates.
Pavel
plan is
Robert Haas [EMAIL PROTECTED] writes:
I am blind, I didn't find any reason, why materialisation isn't useable.
I believe it's because of these two (closely related) problems:
# The basic
# implementation clearly ought to be to dump the result of the subquery
# into a tuplestore and then
Jeff == Jeff Davis [EMAIL PROTECTED] writes:
Jeff * Mutual Recursion:
This limitation isn't at all uncommon in other implementations; DB2
docs for example say:
If more than one common table expression is defined in the same
statement, cyclic references between the common table expressions are
Jeff Davis [EMAIL PROTECTED] writes:
* Mutual Recursion:
with recursive
foo(i) as (values(1) union all select i+1 from bar where i 10),
bar(i) as (values(1) union all select i+1 from foo where i 10)
select * from foo;
ERROR: mutual recursive call is not supported
The
On Mon, 2008-09-08 at 21:13 +0100, Gregory Stark wrote:
Jeff Davis [EMAIL PROTECTED] writes:
* Mutual Recursion:
with recursive
foo(i) as (values(1) union all select i+1 from bar where i 10),
bar(i) as (values(1) union all select i+1 from foo where i 10)
select * from
On Mon, 2008-09-08 at 18:08 +0100, Andrew Gierth wrote:
Jeff * Mutual Recursion:
This limitation isn't at all uncommon in other implementations; DB2
docs for example say:
As with some other things in my list, this doesn't need to be supported
in 8.4. I just wanted to lay out my
Jeff == Jeff Davis [EMAIL PROTECTED] writes:
Jeff Aggregates should be blocked according to the standard.
Jeff Also, causes an infinite loop. This should be fixed for 8.4.
Does the standard require anywhere that non-conforming statements
must be diagnosed? (seems impractical, since it
On Mon, 2008-09-08 at 22:53 +0100, Andrew Gierth wrote:
Yes, you've misinterpreted. When the spec says that a query shall
not do such-and-such, it means that a conforming client isn't allowed
to do that, it does NOT mean that the server is required to produce an
error when it sees it.
Thanks for the review.
[I dropped [EMAIL PROTECTED] from the Cc list since he has left our
company and the email address is being deleted.]
I'm going to look into issues which are seem to be bug (of course if
you know what to fix, patches are always welcome:-).
These are my initial comments
Thanks for the review.
[I dropped [EMAIL PROTECTED] from the Cc list since he has left our
company and the email address is being deleted.]
I'm going to look into issues which are seem to be bug (of course if
you know what to fix, patches are always welcome:-).
These are my initial comments
* Single Evaluation:
with
foo(i) as (select random() as i)
select * from foo union all select * from foo;
i
---
0.233165248762816
0.62126633618027
(2 rows)
The standard specifies that non-recursive WITH should be evaluated
once.
What
65 matches
Mail list logo
