Re: WITH RECUSIVE patches 0723
От | Pavel Stehule |
---|---|
Тема | Re: WITH RECUSIVE patches 0723 |
Дата | |
Msg-id | 162867790807282342p61cf7fcem75c99f8af4a075e1@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WITH RECUSIVE patches 0723 (Martijn van Oosterhout <kleptog@svana.org>) |
Список | pgsql-hackers |
Hello 2008/7/29 Martijn van Oosterhout <kleptog@svana.org>: > On Mon, Jul 28, 2008 at 07:57:16PM +0100, Andrew Gierth wrote: >> Which will be a serious pessimization in many common cases if you do >> it all the time. Googling for examples of non-recursive WITH queries >> shows that it is very widely used for clarity or convenience, in >> contexts where you _don't_ want materialization. > > Since the problem is using the result of a WITH clause more than once, > would it be sufficient to simply detect that case and bail? You don't > want materialisation is most cases, there's just a few where it is > needed. > I thing so materialisation is more important than you thing. Without materialisation I could use derived tables, but materialisation in WITH statement is unique feature usefull for analytical queries. I am sure, so materialisation should be one from possible strategies. I like to see this feature in core, with/without materialisation is usefull for recursive queries and I thing so materialisation should be add in next months. I don't see it as mayor break. I prefere early commit of this patch (with neccessary documentation), because there will be some work that cannot be commited concurently - analytic queries and my implementation of rollup and cube operator. Regards Pavel Stehule > Have a nice day, > -- > Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ >> Please line up in a tree and maintain the heap invariant while >> boarding. Thank you for flying nlogn airlines. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIjkcuIB7bNG8LQkwRAto4AJwPkKlCWD/yBjAyEBL/LXMLK08LPwCfZ2dq > qSHGPoPPGwGIQOP62eQimGE= > =Yog+ > -----END PGP SIGNATURE----- > >
В списке pgsql-hackers по дате отправления: