Re: [HACKERS] Proposal: Local indexes for partitioned table - Mailing list pgsql-hackers

From David Rowley
Subject Re: [HACKERS] Proposal: Local indexes for partitioned table
Date
Msg-id CAKJS1f-HhHtfZToz=t5nzxHZi8TE3-AVy1r58EDSGtfNRWvcAw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Proposal: Local indexes for partitioned table  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [HACKERS] Proposal: Local indexes for partitioned table  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
Re: [HACKERS] Proposal: Local indexes for partitioned table  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On 15 November 2017 at 06:49, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
Here's the remaining bits, rebased.

 I wonder if it should be this patches job to alter the code in get_relation_info() which causes the indexes not to be loaded for partitioned tables:

/*
* Make list of indexes.  Ignore indexes on system catalogs if told to.
* Don't bother with indexes for an inheritance parent, either.
*/
if (inhparent ||
(IgnoreSystemIndexes && IsSystemRelation(relation)))
hasindex = false;
else
hasindex = relation->rd_rel->relhasindex;

A partitioned table will always go into the hasindex = false code path.

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.

What do you think?

--
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [HACKERS] path toward faster partition pruning
Next
From: Paul Ramsey
Date:
Subject: Re: Inlining functions with "expensive" parameters