Re: Declarative partitioning
| От | Ashutosh Bapat |
|---|---|
| Тема | Re: Declarative partitioning |
| Дата | |
| Msg-id | CAFjFpRfOkr1aiQ0bk_DWp_GsPgZsOaZ9RAs0BFoTWwR2xzfzxA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Declarative partitioning (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
| Ответы |
Re: Declarative partitioning
|
| Список | pgsql-hackers |
On 2016/04/15 18:46, Ashutosh Bapat wrote:
>
> 3. PartitionKeyData contains KeyTypeCollInfo, whose contents can be
> obtained by calling functions exprType, exprTypemod on partexprs. Why do we
> need to store that information as a separate member?
There was no KeyTypeCollInfo in early days of the patch and then I found
myself doing a lot of:
partexprs_item = list_head(key->partexprs);
for (attr in key->partattrs)
{
if (attr->attnum != 0)
{
// simple column reference, get type from attr
}
else
{
// expression, get type using exprType, etc.
partexprs_item = lnext(partexprs_item);
}
}
At least the two loops can be flattened to a single loop if we keep only expressions list with attributes being just Var nodes. exprType() etc. would then work seemlessly.
That ended up being quite a few places (though I managed to reduce the
number of places over time). So, I created this struct which is
initialized when partition key is built (on first open of the partitioned
table).
Hmm, I am just afraid that we might end up with some code using cached information and some using exprType, exprTypmod etc.
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
В списке pgsql-hackers по дате отправления: