Proposal: partition pruning by secondary attributes

From: Ildar Musin <i(dot)musin(at)postgrespro(dot)ru>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Proposal: partition pruning by secondary attributes
Date: 2018-02-08 11:21:34
Message-ID: 5fd17d8a-d64e-e5b2-3fd8-a99062974486@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello, hackers!

Sorry if this have already been discussed. I've had this idea some time
ago and then successfully forgot about it until pgconf.ru, where I had a
conversation with one of postgres users. His situation could be
described as this: they have a table with id, timestamp and some other
attributes, which is partitioned by (let's say) timestamp column. In
different contexts they may want to filter the table either by id or by
timestamp attribute (but not both). In this case pruning will only work
for timestamp column.

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. And it will have
similar limitations. For example, we may benefit if secondary attribute
values are monotonically increase or decrease, but would be unhelpful if
they are scattered, or if table wasn't partitioned by range.

I wanted to ask community's opinion would it be worth considering.
Thanks!

--
Ildar Musin
i(dot)musin(at)postgrespro(dot)ru

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2018-02-08 12:25:44 Re: In logical replication concurrent update of partition key creates a duplicate record on standby.
Previous Message Etsuro Fujita 2018-02-08 10:16:04 Re: non-bulk inserts and tuple routing