| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
| Cc: | Ildar Musin <i(dot)musin(at)postgrespro(dot)ru>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proposal: partition pruning by secondary attributes |
| Date: | 2018-02-08 18:01:38 |
| Message-ID: | 20180208180138.5cjrgfgythjiurca@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2018-02-08 14:48:34 -0300, Alvaro Herrera wrote:
> Ildar Musin wrote:
>
> > The idea is to store min and max values of secondary attributes (like
> > 'id' in the example above) for each partition somewhere in catalog and
> > use it for partition pruning along with partitioning key. You can think
> > of it as somewhat like BRIN index but for partitions.
>
> What is the problem with having a BRIN index?
Building plans to scan the individual partitions, lock them, open the
relevant files, etc is often going to be significantly more expensive
than pruning at plan time.
But there also seems to be a number of fairly nasty locking issues with
this proposal, leaving the amount of required code aside.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rafal Pietrak | 2018-02-08 18:02:23 | Re: it's a feature, but it feels like a bug |
| Previous Message | Alvaro Herrera | 2018-02-08 17:58:21 | Re: [HACKERS] path toward faster partition pruning |