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

From David Rowley
Subject Re: [HACKERS] path toward faster partition pruning
Date
Msg-id CAKJS1f_wF2PYs=MV+Yw2U=+=dsmcJ5Qd_tm0U6ZoRhqxDfs=LQ@mail.gmail.com
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  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
On 24 March 2018 at 01:15, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> In the updated patch (that is, after incorporating your changes), I have
> moved this partsupfunc switching to the caller of partkey_datum_from_expr
> instead of doing it there.  New patch also checks that returned function
> OID is valid, which if not we don't use the expression's value for pruning.

Thanks for accepting those changes.

> So now. we statically allocate a partsupfunc array on every invocation of
> perform_pruning_base_step() or of get_partitions_excluded_by_ne_datums().
> Considering run-time pruning, we may have to find some other place to
> cache that.

hmm yeah, it's not perfect, but I don't have any better ideas for now,
apart from this probably could be done when creating the steps rather
than executing them. That would save having to look up the correct
function Oid during execution, and save bothering to create steps
values that we simply can't compare to the partition key.

I've done this in the attached patch against v39.

I also renamed argvalues to argexprs, since they're not values.  The
PartClauseInfo could probably do with the same change too, but I
didn't touch it.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] why not parallel seq scan for slow functions
Next
From: Amit Kapila
Date:
Subject: Re: Re: GSOC 2018 Ideas