Re: [HACKERS] Default Partition for Range

Поиск
Список
Период
Сортировка
От Jeevan Ladhe
Тема Re: [HACKERS] Default Partition for Range
Дата
Msg-id CAOgcT0PhA7aS-UtOKCz61iEvhGxFY9t+Aimt4_y74RZtY-cd4w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Default Partition for Range  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Default Partition for Range  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Hi Robert, Beena,

On Wed, Aug 9, 2017 at 5:53 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Aug 9, 2017 at 8:18 AM, Rajkumar Raghuwanshi
<rajkumar.raghuwanshi@enterprisedb.com> wrote:
> --difference in the description of default partition in case of list vs
> range
>
> create table lp (a int) partition by list(a);
> create table lp_d partition of lp DEFAULT;
> postgres=# \d+ lp_d
>                                    Table "public.lp_d"
>  Column |  Type   | Collation | Nullable | Default | Storage | Stats target
> | Description
> --------+---------+-----------+----------+---------+---------+--------------+-------------
>  a      | integer |           |          |         | plain   |
> |
> Partition of: lp DEFAULT
> Partition constraint:
>
> create table rp (a int) partition by range(a);
> create table rp_d partition of rp DEFAULT;
> postgres=# \d+ rp_d
>                                    Table "public.rp_d"
>  Column |  Type   | Collation | Nullable | Default | Storage | Stats target
> | Description
> --------+---------+-----------+----------+---------+---------+--------------+-------------
>  a      | integer |           |          |         | plain   |
> |
> Partition of: rp DEFAULT
> Partition constraint: true

This looks like a problem with the default list partitioning patch.  I
think "true" is what we expect to see here in both cases.

In case of list partition if there is only default partition, then there is no
specific value set that can be excluded from default partition, so in
such a case DEFAULT partition for a list partitioned table simply will
not have any constraint on it, and hence while the describe output is
printed it does not have any constraints to be printed.

Whereas, in case of default partition for a range partitioned table, in
get_qual_for_range() it creates true boolean expression if default is the
only partition. Here is the relevent code from Beena's patch:

+ else /* default is the only partition */
+ result = list_make1(makeBoolConst(true, false));

I think, it is unnecessary to create a constraint that is going to be always
true. Instead, if we have no constraints we can avoid some extra cpu
cycles which would otherwise be wasted in evaluating an expression
that is going to be always true.

Having said this, I see a point that in such a case we should have
some neat meaningful content to be printed for "Partition constraint: ".
I think we can address this when we construct describe output string.

Some ideas that come to my mind are:
Partition constraint: NIL
Partition constraint: no constraints
No partition constraint.
Partition constraint: true

Please let me know your thoughts.

Regards,
Jeevan Ladhe  

В списке pgsql-hackers по дате отправления:

Предыдущее
От: AP
Дата:
Сообщение: Re: [HACKERS] pgsql 10: hash indexes testing
Следующее
От: Sokolov Yura
Дата:
Сообщение: Re: [HACKERS] Walsender timeouts and large transactions