Skip site navigation (1) Skip section navigation (2)

Re: Nested CASE-WHEN scoping

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Nested CASE-WHEN scoping
Date: 2011-05-30 12:25:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 26.05.2011 00:31, Tom Lane wrote:
> The main annoyance here is that standalone expressions may now need
> Param slots to execute, which will complicate places that need to
> evaluate them, but there's probably no way around that

Yeah, I can see two complications:

1. Domain constraints

Domain constraint check expressions are fetched and constant-folded 
separately from the enclosing expression, in ExecInitExpr(). In order to 
allocate distinct paramids for any CASE values within the domain check 
expression, we'd need to know how many paramids are in use in the parent 
expression. We could dig into the parent PlanState and its EState to get 
that, but we don't have that for stand-alone expressions.

2. Index expressions

Index expressions are stored in relcache after constant evaluation, so 
any CaseTestExprs will already be replaced with Params. When the recheck 
expression is evaluated, the paramids used in the recheck expression 
will clash with real PARAM_EXEC params used to pass values up and down 
subqueries, as well as any params used for CASEs.

I think we can work around both of those by just saving and restoring 
the value of each Param that we set while evaluating an expression, as 
the values should not be used simultaneously, but it makes me a bit 
uncomfortable. If we ever try to inline those expressions into other 
expressions, we'll be right back to the issue we have with nested CASE 
now. I'm not sure if we might already do that for index recheck 
expressions. Alternatively, we could adjust the paramids when an 
expression is inlined into another, similar to what OffsetVarNodes does 
for Vars.

For debugging purposes, it seems like a good idea to invent a new kind 
of Param for these, and keep them separate from PARAM_EXEC params. The 
scope would be different, PARAM_EXECs are used to pass values between 
planner nodes, while these new kind of Params would be used to pass 
values within a single expression.

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2011-05-30 12:45:23
Subject: Re: Getting a bug tracker for the Postgres project
Previous:From: Nick RajDate: 2011-05-30 10:43:59
Subject: Cube Index Size

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group