pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedVALUES clause memory optimization (was: Values list-of-targetlists patch...)
2+ messages / 2 participants
[nested] [flat]
* VALUES clause memory optimization (was: Values list-of-targetlists patch...)
@ 2006-08-03 00:18 Joe Conway <mail@joeconway.com>
2006-08-03 12:48 ` Re: VALUES clause memory optimization (was: Values list-of-targetlists patch...) Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 2+ messages in thread
From: Joe Conway @ 2006-08-03 00:18 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Hackers (PostgreSQL) <pgsql-hackers@postgresql.org>
Tom Lane wrote:
> I think we could safely list_free the input list in transformInsertRow
> as your patch suggests, which would buy back the 144M part. But I don't
> believe it's safe at all to free the raw_parser output --- the grammar
> sometimes makes multiple links to the same subtree, eg in BETWEEN.
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?
Joe
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: VALUES clause memory optimization (was: Values list-of-targetlists patch...)
2006-08-03 00:18 VALUES clause memory optimization (was: Values list-of-targetlists patch...) Joe Conway <mail@joeconway.com>
@ 2006-08-03 12:48 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 2+ messages in thread
From: Tom Lane @ 2006-08-03 12:48 UTC (permalink / raw)
To: Joe Conway <mail@joeconway.com>; +Cc: Hackers (PostgreSQL) <pgsql-hackers@postgresql.org>
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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2006-08-03 12:48 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-08-03 00:18 VALUES clause memory optimization (was: Values list-of-targetlists patch...) Joe Conway <mail@joeconway.com>
2006-08-03 12:48 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox