Re: VALUES clause memory optimization (was: Values list-of-targetlists patch...) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: VALUES clause memory optimization (was: Values list-of-targetlists patch...)
Date
Msg-id 2922.1154609337@sss.pgh.pa.us
Whole thread Raw
In response to VALUES clause memory optimization (was: Values list-of-targetlists patch...)  (Joe Conway <mail@joeconway.com>)
Responses Re: VALUES clause memory optimization  (Joe Conway <mail@joeconway.com>)
List pgsql-hackers
Joe Conway <mail@joeconway.com> writes:
> In transformExpr the comment implies that it should be safe to reapply
> to an already transformed expression. What if we free the raw_parser
> expression list/cells/nodes and replace it with the as-transformed one?

How are you going to do the "replace" bit?  The entire problem is that
you don't know where are all the down-links leading to the subexpression
you are currently working on.

The reason we could safely list_free inside transformInsertRow is that
we know all its callers have just built the passed-in list and so there
are no other pointers to it.  That doesn't apply in the general case of
grammar output.

I think in the long run we probably ought to fix things so that the
grammar never outputs any multiply-linked trees; that little shortcut
has been a continuing source of grief for many reasons.  I can't see
doing that for 8.2 though.  My advice is to get that low-hanging fruit
in transformInsertRow and leave the other ideas for 8.3.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Standby Mode
Next
From: Tom Lane
Date:
Subject: Re: pg_terminate_backend