Re: [PATCHES] WITH RECURSIVE updated to CVS TIP

From: Yoshiyuki Asaba <y-asaba(at)sraoss(dot)co(dot)jp>
To: postgres(at)cybertec(dot)at
Cc: david(at)fetter(dot)org, pgsql-patches(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCHES] WITH RECURSIVE updated to CVS TIP
Date: 2008-07-07 07:22:21
Message-ID: 20080707.162221.725436840180024396.y-asaba@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Hi,

From: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>
Subject: Re: [PATCHES] [HACKERS] WITH RECURSIVE updated to CVS TIP
Date: Sat, 5 Jul 2008 10:43:57 +0200

> i did some quick testing with this wonderful patch.
> it seems there are some flaws in there still:
>
> test=# explain select count(*)
> test-# from ( WITH RECURSIVE t(n) AS ( SELECT 1 UNION ALL
> SELECT DISTINCT n+1 FROM t )
> test(# SELECT * FROM t WHERE n < 5000000000) as t
> test-# WHERE n < 100;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
> !> \q
>
> this one will kill the planner :(
> removing the (totally stupid) distinct avoids the core dump.

Thanks. I've fixed on local repository.

> i found one more issue;
>
> -- broken: wrong result
> test=# select count(*) from ( WITH RECURSIVE t(n) AS (
> SELECT 1 UNION ALL SELECT n + 1 FROM t)
> SELECT * FROM t WHERE n < 5000000000) as t WHERE n < (
> select count(*) from ( WITH RECURSIVE t(n) AS (
> SELECT 1 UNION ALL SELECT n + 1 FROM t )
> SELECT * FROM t WHERE n < 5000000000) as t WHERE n < 100) ;

I've fixed. However, this query enters infinite loop.

WITH RECURSIVE t(n) AS (
SELECT 1 UNION ALL SELECT n + 1 FROM t)
SELECT * FROM t WHERE n < 5000000000

The planner distributed WHERE-clause into WITH-clause with previous
recursive-patch.

WITH RECURSIVE t(n) AS (
SELECT 1 WHERE n < 5000000000
UNION ALL
SELECT n + 1 FROM t WHERE n < 5000000000)
SELECT * FROM t;

This optimization is in qual_is_pushdown_safe(). So, I've fixed not to
optimize WITH-clause in the function.

Regards,
--
Yoshiyuki Asaba
y-asaba(at)sraoss(dot)co(dot)jp

>
> if i am not totally wrong, this should give us a different result.
>
> i am looking forward to see this patch in core :).
> it is simply wonderful ...
>
> many thanks,
>
> hans
>
>
>
>
>
>
> On Jul 3, 2008, at 1:11 AM, David Fetter wrote:
>
> > Folks,
> >
> > Please find patch enclosed, including some documentation.
> >
> > Can we see about getting this in this commitfest?
> >
> > Cheers,
> > David.
> > --
> > David Fetter <david(at)fetter(dot)org> http://fetter.org/
> > Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
> > Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
> >
> > Remember to vote!
> > Consider donating to Postgres: http://www.postgresql.org/about/
> > donate<recursive_query-7.patch.bz2>
> > --
> > Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-hackers
>
>
>
> --
> Cybertec Schönig & Schönig GmbH
> PostgreSQL Solutions and Support
> Gröhrmühlgasse 26, 2700 Wiener Neustadt
> Tel: +43/1/205 10 35 / 340
> www.postgresql-support.de, www.postgresql-support.com
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zdenek Kotala 2008-07-07 07:46:10 Re: PATCH: CITEXT 2.0
Previous Message Simon Riggs 2008-07-07 07:10:00 Re: [PATCHES] WIP: executor_hook for pg_stat_statements

Browse pgsql-patches by date

  From Date Subject
Next Message Alvaro Herrera 2008-07-07 13:45:33 Re: [PATCHES] GIN improvements
Previous Message Simon Riggs 2008-07-07 07:10:00 Re: [PATCHES] WIP: executor_hook for pg_stat_statements