On Fri, Aug 5, 2016 at 5:21 PM, Robert Haas <robertmh...@gmail.com> wrote:

> On Fri, Aug 5, 2016 at 6:53 AM, Ashutosh Bapat
> <ashutosh.ba...@enterprisedb.com> wrote:
> > The lists for list partitioned tables are stored as they are specified by
> > the user. While searching for a partition to route tuple to, we compare
> it
> > with every list value of every partition. We might do something better
> > similar to what's been done to range partitions. The list of values for a
> > given partition can be stored in ascending/descending sorted order. Thus
> a
> > binary search can be used to check whether given row's partition key
> column
> > has same value as one in the list. The partitions can then be stored in
> the
> > ascending/descending order of the least/greatest values of corresponding
> > partitions.
> +1.  Here as with range partitions, we must be sure to know which
> opclass should be used for the comparisons.
> > We might be able to eliminate search in a given partition if its
> > lowest value is higher than the given value or its higher value is lower
> > than the given value.
> I don't think I understand this part.

Consider lists ('e', 'i', 'f'), ('h', 'd','m') and ('l', 'b', 'a') for a
list partitioned tables. I am suggesting that we arrange them as
('a','b','l'), ('d', 'h', 'm') and ('e', 'f', 'i'). If the given row
(either for comparison or for inserting) has value 'c', we will search for
it in ('a','b','l') but will be eliminate other two partitions since the
second's partition's lowest value is higher than 'c' and lowest values of
rest of the partitions are higher than that of the second partition.
Without this order among the partitions, we will have to compare lowest
values of all the partitions.
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

Reply via email to