From: | Marti Raudsepp <marti(at)juffo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [WIP] Caching constant stable expressions per execution |
Date: | 2011-09-12 21:27:48 |
Message-ID: | CABRT9RCc5JAzUB_gYEwNTL2Z7NuXUEL6akwHToqpr6uam9NJPg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 12, 2011 at 00:22, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Well, people seem to think that this is worth pursuing, so here's a
> couple of thoughts about what needs to be done to get to something
> committable.
Thanks, that's exactly the kind of feedback I need.
> IMO this is no good because it means that every intermediate result
> computed within the cacheable expression will be leaked into
> per_query_memory.
Agreed, that's not ideal.
> type CacheExpr (that's just the first name that came to mind, maybe
> somebody has a better idea)
StableConstExpr? But we can leave the bikeshedding for later :)
> The planner would have to figure out where to inject
> CacheExpr nodes into expression trees --- ideally only the minimum
> number of nodes would be added.
Yeah, that occured to me, but seemed complicated at first, so I didn't
want to do it before having a confirmation from the list. However,
after looking at the expression tree walking code for a bit, it
doesn't seem that scary anymore.
> The other thing that is going to be an issue is that I'm fairly sure
> this breaks plpgsql's handling of simple expressions.
Oh, I would have never thought of that.
Regards,
Marti
From | Date | Subject | |
---|---|---|---|
Next Message | Dermot | 2011-09-12 21:33:16 | Sponsored development |
Previous Message | Joshua D. Drake | 2011-09-12 21:22:40 | Re: augmenting MultiXacts to improve foreign keys |