Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> 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.

OK, I'll take a look at that (actually I was just in that general vicinity anyway).

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?

Sure, sounds good to me.


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to