From: | Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, Beena Emerson <memissemerson(at)gmail(dot)com>, Rahila Syed <rahilasyed90(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Default Partition for Range |
Date: | 2017-08-10 10:56:12 |
Message-ID: | CAOgcT0PhA7aS-UtOKCz61iEvhGxFY9t+Aimt4_y74RZtY-cd4w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Robert, Beena,
On Wed, Aug 9, 2017 at 5:53 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Aug 9, 2017 at 8:18 AM, Rajkumar Raghuwanshi
> <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Sokolov Yura | 2017-08-10 11:20:17 | Re: Walsender timeouts and large transactions |
Previous Message | AP | 2017-08-10 10:41:37 | Re: pgsql 10: hash indexes testing |