Re: Proposal: partition pruning by secondary attributes

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Ildar Musin <i(dot)musin(at)postgrespro(dot)ru>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: partition pruning by secondary attributes
Date: 2018-02-09 12:42:18
Message-ID: 20180209124218.lhnhmtde74iv5gnj@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ildar Musin wrote:

> But if we filter the table by 'id' then planner has no other way but to
> append every partition to the plan.
>
> EXPLAIN (COSTS OFF) SELECT * FROM events WHERE id = 123;
> Append
> -> Seq Scan on events_0
> Filter: (id = 123)
> -> Seq Scan on events_1
> Filter: (id = 123)
> -> Seq Scan on events_2
> Filter: (id = 123)

I think it should be possible to prune at runtime based on a brin index.
As Andres says this means we cannot prune at plan time, and you still
need to open the relations and indexes to perform pruning, but the
contention problem is solved.

A pretty crazy related idea is to allow BRIN indexes to be global -- so
you create a brin index on the partitioned table in such a way that it
doesn't cascade to create local indexes, but instead a single index
represents the whole hierarchy. This requires a lot of other changes,
but seems to match your design.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2018-02-09 12:53:39 Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental)
Previous Message Amit Langote 2018-02-09 12:36:32 Re: [HACKERS] path toward faster partition pruning