Re: Problem with default partition pruning - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Problem with default partition pruning
Date
Msg-id 20190812174509.GA11692@alvherre.pgsql
Whole thread Raw
In response to Re: Problem with default partition pruning  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Problem with default partition pruning  (Simon Riggs <simon@2ndquadrant.com>)
Re: Problem with default partition pruning  (Amit Langote <amitlangote09@gmail.com>)
List pgsql-hackers
v3-0001 still seems to leave things a bit duplicative.  I think we can
make it better if we move the logic to set RelOptInfo->partition_qual to
a separate routine (set_baserel_partition_constraint mirroring the
existing set_baserel_partition_key_exprs), and then call that from both
places that need access to partition_qual.

So I propose that the attached v4 patch should be the final form of this
(also rebased across today's list_concat API change).  I verified that
constraint exclusion is not being called by partprune unless a default
partition exists (thanks errbacktrace()); I think that should appease
Simon's performance concern for the most common case of default
partition not existing.

I think I was not really understanding the comments being added by
Amit's v3, so I reworded them.  I hope I understood the intent of the
code correctly.

I'm not comfortable with RelOptInfo->partition_qual.  But I'd rather
leave that for another time.

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

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Add "password_protocol" connection parameter to libpq
Next
From: Peter Eisentraut
Date:
Subject: Re: Add "password_protocol" connection parameter to libpq