Re: [WIP] Caching constant stable expressions per execution

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

In response to

Responses

Browse pgsql-hackers by date

  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