Horton

Re: [HACKERS] Proposal: Local indexes for partitioned table

Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>

View thread View on postgr.es
From: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Simon Riggs <simon@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Maksim Milyutin <milyutinma@gmail.com>
Date: 2017-11-20T08:38:22Z
Lists: pgsql-hackers 
On Fri, Nov 17, 2017 at 6:24 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
>
> I'm kind of thinking this patch should change that, even if the patch is not
> making use of the indexes, you could argue that something using
> set_rel_pathlist_hook might want to do something there, although, there's
> likely a bunch of counter arguments too.
>

How do you think optimizer would use this information? A partitioned
table which doesn't have data doesn't need that information.

Partitioned table's behaviour here is similar to that of the
inheritance parent. Even though an inheritance parent may have indexes
on it, that information is not read and stored by optimizer for that
table in its role as an inheritance parent. It stores and uses that
information for that table in its role as the child, which gets
scanned.

May be in future, we will try to create common index paths for all
children for the indexes which are inherited from the parent. Then we
might want to load the index information for partitioned table as
well, but I don't think we are any close to do that.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company

Commits

  1. Local partitioned indexes

  2. Fix StoreCatalogInheritance1 to use 32bit inhseqno

  3. Get rid of copy_partition_key

  4. Simplify index_[constraint_]create API