X-Original-To: pgsql-patches-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 1A7599FB2F8 for ; Sat, 29 Jul 2006 22:27:58 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 17785-08 for ; Sat, 29 Jul 2006 22:27:53 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 32EED9FB2F7 for ; Sat, 29 Jul 2006 22:27:23 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k6U1RKFY021321; Sat, 29 Jul 2006 21:27:20 -0400 (EDT) To: Joe Conway cc: "Patches (PostgreSQL)" Subject: Re: [HACKERS] 8.2 features? In-reply-to: <44CB051D.6090609@joeconway.com> References: <200607281947.k6SJlOI02533@momjian.us> <473.1154116455@sss.pgh.pa.us> <44CA76A9.8070101@joeconway.com> <44CB051D.6090609@joeconway.com> Comments: In-reply-to Joe Conway message dated "Fri, 28 Jul 2006 23:50:05 -0700" Date: Sat, 29 Jul 2006 21:27:20 -0400 Message-ID: <21320.1154222840@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.054 tagged_above=0 required=5 tests=AWL, SPF_HELO_PASS, SPF_PASS X-Spam-Level: X-Archive-Number: 200607/320 X-Sequence-Number: 20474 Joe Conway writes: >> I'm afraid though that after 2 or so days heading down the last path you >> suggested (namely making a new jointree leaf node) I was having trouble, >> and at the same time came to the conclusion that adding a new RTE was >> alot cleaner and made more sense to me. So I'm hoping you won't want to >> send me back to the drawing board again. I believe I have cleaned up the >> things you objected to: I was just objecting to having both a new RTE type and a new jointree node type --- you only need one or the other. Opting for the new RTE type is fine with me, and it probably is a bit cleaner at the end of the day. I still dislike the way you're doing things in the executor though. I don't see the point of using the execScan.c machinery; most of the time that'll be useless overhead. As I said before, I think the right direction here is to split Result into two single-purpose node types and make the non-filter version capable of taking a list of targetlists. As far as reducing memory use goes, it seems to me that there's no need for the individual "targetlists" to have ResTarget/TargetEntry decoration. For the simple case where the expressions are just Const nodes, this could save something like a third of the space (there's also a List node per item, which we can't do much about). I think we'd have to gin up a fake targetlist to attach to the Plan node, but there'd be only one. Since the result-node split is my hot button, I'm willing to volunteer to make it happen. Do you want to concentrate on the remaining parser-area issues and leave the executor part to me? regards, tom lane