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
>
On 08.02.2018 21:01, Andres Freund wrote:
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 wit
On Thu, Feb 8, 2018 at 4:51 PM, 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.
Every insertion and update of secondary
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 thin
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.
Wha
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
a
