Re: [PATCH] Caching for stable expressions with constant arguments v3

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: [PATCH] Caching for stable expressions with constant arguments v3
Date: 2011-12-06 22:29:22
Message-ID: CABRT9RB7rdvke7JHg853fnJO42DyxagS0EuX1fojMfY7=tAxVA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 5, 2011 at 21:04, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Yet another idea would be to leave the CacheExprs there, but provide a way
> to reset the caches. PL/pgSQL could then reset the caches between every
> invocation. Or pass a flag to ExecInitExpr() to skip through the CacheExprs.

Great idea, I've ripped out all the conditional CacheExpr generation
logic from the planner and added a new boolean to CacheExprState
instead. This makes me happy as I'm now rid of most kludgy bits and
reduced the patch size somewhat. This also solves Tom's concern.

ExecInitExpr enables the cache when its 'PlanState *parent' attribute
isn't NULL. On the one hand this works out well since PlanState always
has a predictable life cycle thus caching is always safe.

On the other hand, a few places lose caching support this way since
they don't go through the planner:
* Column defaults in a COPY FROM operation. Common use case is
'timestamp default now()'
This might be a significant loss in some data-loading scenarios.
* ALTER TABLE t ALTER col TYPE x USING some_expr(); No big loss here.

Regards,
Marti

Attachment Content-Type Size
cacheexpr-v4-wip.patch text/x-patch 79.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-12-07 00:18:24 Re: Inlining comparators as a performance optimisation
Previous Message Pavel Stehule 2011-12-06 22:24:50 Re: ecmascript 5 DATESTYLE