Re: [HACKERS] Default Partition for Range - Mailing list pgsql-hackers
| From | Jeevan Ladhe |
|---|---|
| Subject | Re: [HACKERS] Default Partition for Range |
| Date | |
| Msg-id | CAOgcT0PhA7aS-UtOKCz61iEvhGxFY9t+Aimt4_y74RZtY-cd4w@mail.gmail.com Whole thread Raw |
| In response to | Re: [HACKERS] Default Partition for Range (Robert Haas <robertmhaas@gmail.com>) |
| Responses |
Re: [HACKERS] Default Partition for Range
(Robert Haas <robertmhaas@gmail.com>)
|
| List | 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 by date: