Re: [HACKERS] path toward faster partition pruning - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: [HACKERS] path toward faster partition pruning
Date
Msg-id 20171229130213.htk7pn5vfercayxz@alvherre.pgsql
Whole thread Raw
In response to Re: [HACKERS] path toward faster partition pruning  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: [HACKERS] path toward faster partition pruning  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List pgsql-hackers
I happened to notice that Ashutosh's patch series at
https://www.postgresql.org/message-id/CAFjFpReJhFSoy6DqH0ipFSHd=sLNEkSzAtz4VWCaS-w2jZL=uw@mail.gmail.com
has a 0001 patch that modifies the partition_bound_cmp stuff too.
Are those conflicting?

Ashutosh's commit message:
    Modify bound comparision functions to accept members of PartitionKey

    Functions partition_bound_cmp(), partition_rbound_cmp() and
    partition_rbound_datum_cmp() are required to merge partition bounds
    from joining relations. While doing so, we do not have access to the
    PartitionKey of either relations. So, modify these functions to accept
    only required members of PartitionKey so that the functions can be
    reused for merging bounds.

Amit's:
    Some interface changes for partition_bound_{cmp/bsearch}

    Introduces a notion of PartitionBoundCmpArg, which replaces the set
    of arguments void *probe and bool probe_is_bound of both
    partition_bound_cmp and partition_bound_bsearch.  It wasn't possible
    before to specify the number of datums when a non-bound type of
    probe is passed.  Slightly tweaking the existing interface to allow
    specifying the same seems awkward.  So, instead encapsulate that
    into PartitionBoundCmpArg.  Also, modify partition_rbound_datum_cmp
    to compare caller-specifed number of datums, instead of
    key->partnatts datums.


-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: "Tels"
Date:
Subject: Re: plpgsql function startup-time improvements
Next
From: "Tels"
Date:
Subject: Re: TAP test module - PostgresClient